classification
Title: logging.Manager.logRecordFactory is never used
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.8, Python 3.7, Python 3.6, Python 3.5, Python 3.4, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: feinsteinben, vinay.sajip
Priority: normal Keywords: patch

Created on 2018-03-12 16:18 by feinsteinben, last changed 2018-06-05 16:37 by vinay.sajip. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 6087 open feinsteinben, 2018-03-12 17:42
Messages (8)
msg313662 - (view) Author: Ben Feinstein (feinsteinben) * Date: 2018-03-12 16:18
In logging.Manager, the logRecordFactory attribute is never used.

One would expect that makeRecord() (in logging.Logger) would generate a record using its manager's logRecordFactory, or fallback to the global _logRecordFactory (if has no manager, or manager.logRecordFactory is None), but the latter is used exclusively.
msg313834 - (view) Author: Ben Feinstein (feinsteinben) * Date: 2018-03-14 18:18
Here is a code that demonstrate the bug:

```python
import logging

class LogRecordTypeFilter(logging.Filter):
    def __init__(self, cls):
        self.cls = cls

    def filter(self, record):
        t = type(record)
        if t is not self.cls:
            msg = 'Unexpected LogRecord type %s, expected %s' % (t, self.cls)
            raise TypeError(msg)
        return True

class MyLogRecord(logging.LogRecord):
    pass

manager = logging.Manager(None)
manager.setLogRecordFactory(MyLogRecord)
logger = manager.getLogger('some_logger')
logger.addFilter(LogRecordTypeFilter(MyLogRecord))

try:
    logger.error('bpo-33057')
except TypeError as e:
    print(e)  # output: Unexpected LogRecord type <class 'logging.LogRecord'>, expected <class '__main__.MyLogRecord'>
```
msg313853 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-03-15 05:25
The logRecordFactory attribute was added but never used and is part of an internal API (the Manager isn't documented, on purpose). Why do you need a manager-specific factory?
msg313859 - (view) Author: Ben Feinstein (feinsteinben) * Date: 2018-03-15 08:44
I use the logging module to log records of lab experiments. I have two
types of loggers, one for experiment results ("data") and another for
general information. I think that having a different managers for data
loggers is the easiest way to do it.

On Thu, Mar 15, 2018, 07:25 Vinay Sajip <report@bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip@yahoo.co.uk> added the comment:
>
> The logRecordFactory attribute was added but never used and is part of an
> internal API (the Manager isn't documented, on purpose). Why do you need a
> manager-specific factory?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue33057>
> _______________________________________
>
msg313884 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-03-15 14:21
>  I have two types of loggers, one for experiment results ("data") and another for general information

In what way is the behaviour of the two types of logger different? I'm concerned that this might be an XY problem ...
msg313946 - (view) Author: Ben Feinstein (feinsteinben) * Date: 2018-03-16 11:10
General loggers are used in the standard way (message, args, etc), but data
loggers are used for different types of data. Instead of message, they
receive the experiment results (dict/list/np.array/binary data) and their
`formatMessage()` method should be modified in order to account for the
changed data-type.

This might indeed be an XY problem on my side. However, it seems that
someone already thought about it before and started implementing this
mechanism (`Manager.setLogRecordFactory()`), but didn't finish. That's why
I suggested this modification.

On Thu, Mar 15, 2018 at 4:21 PM Vinay Sajip <report@bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip@yahoo.co.uk> added the comment:
>
> >  I have two types of loggers, one for experiment results ("data") and
> another for general information
>
> In what way is the behaviour of the two types of logger different? I'm
> concerned that this might be an XY problem ...
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue33057>
> _______________________________________
>
msg314012 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-03-17 19:44
> However, it seems that someone already thought about it before and started implementing this mechanism

That someone was me. I decided that a single module-level factory was good enough but failed to delete the things you noticed.

From what you've said, it looks more and more like an XY problem and I would guess that your requirement can be solved by either using a custom message object or some other method already supported by existing mechanisms.
msg318765 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-06-05 16:37
I'm closing this, please reopen if you have more information which might change my view.
History
Date User Action Args
2018-06-05 16:37:47vinay.sajipsetstatus: open -> closed
resolution: not a bug
messages: + msg318765

stage: patch review -> resolved
2018-03-17 19:44:39vinay.sajipsetmessages: + msg314012
2018-03-16 11:10:26feinsteinbensetmessages: + msg313946
2018-03-15 14:21:54vinay.sajipsetmessages: + msg313884
2018-03-15 08:44:48feinsteinbensetmessages: + msg313859
2018-03-15 05:25:28vinay.sajipsetmessages: + msg313853
2018-03-14 18:18:57feinsteinbensetmessages: + msg313834
2018-03-12 18:58:09feinsteinbensetfiles: - issue_logRecordFactory.py
2018-03-12 17:42:34feinsteinbensetkeywords: + patch
stage: patch review
pull_requests: + pull_request5848
2018-03-12 16:18:05feinsteinbencreate