[issue38716] logging: rotating handlers set namer and rotator null

[lorb]

New submission from lorb :

When subclassing the rotating handlers of the logging module and implementing a 
namer or rotator method they are silently set to None in __init__. This is 
surprising behaviour and currently the set a specific namer or rotator it is 
required to create an instance first and than set them.

--
messages: 356107
nosy: lorb
priority: normal
severity: normal
status: open
title: logging: rotating handlers set namer and rotator null

___
Python tracker 
<https://bugs.python.org/issue38716>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38716] logging: rotating handlers set namer and rotator null

[lorb]

Change by lorb :


--
keywords: +patch
pull_requests: +16581
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17072

___
Python tracker 
<https://bugs.python.org/issue38716>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38716] logging: rotating handlers set namer and rotator null

[lorb]

lorb  added the comment:

Thanks for the review and response. I don't understand yet why not to
allow the following while keeping the existing functionality. This
could also be achieved by turning the namer and rotator into class
attributes. I recently created a subclass of the timed rotating
handler where it is beneficial for the handler to be able to access to
self to use the rollover time in the naming.

class MyHandler(BaseRotatingHandler):
def namer(self, default_name):
return default_name  # or whatever you want here

def rotator(self, source, dest):
os.rename(source, dest)  # or whatever you want here

Am Mi., 6. Nov. 2019 um 11:35 Uhr schrieb Vinay Sajip :
>
>
> Vinay Sajip  added the comment:
>
> The namer and rotator attributes are callables, not methods to be overridden. 
> You can certainly do this with methods and set them accordingly:
>
> class MyHandler(BaseRotatingHandler):
> def __init__(self, *args, **kwargs):
> super(MyHandler, self).__init__(*args, **kwargs)
> self.namer = self.my_namer
> self.rotator = self.my_rotator
>
> def my_namer(self, default_name):
> return default_name  # or whatever you want here
>
> def my_rotator(self, source, dest):
> os.rename(source, dest)  # or whatever you want here
>
> Having namer and rotator be callables avoids the need to subclass a handler 
> just to override naming and rotating functionality. So, I think this issue 
> should be closed as "not a bug", and the corresponding PR closed. Thanks for 
> your effort, though - I just think you may have misunderstood the intent of 
> the design.
>
> --
> nosy: +vinay.sajip
>
> ___
> Python tracker 
> <https://bugs.python.org/issue38716>
> ___

--

___
Python tracker 
<https://bugs.python.org/issue38716>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38716] logging: rotating handlers set namer and rotator null

[lorb]

lorb  added the comment:

This PR certainly does not turn them into methods. I believe it also
doesn't encourage the idea that they would have to be. All it does is
preventing __init__ from setting them to None in the case they are
defined as methods. Would you consider it more acceptable to just turn
them into class level attributes of BaseRotatingHandler instead of
setting them in init?

--

___
Python tracker 
<https://bugs.python.org/issue38716>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38716] logging: rotating handlers set namer and rotator null

[lorb]

lorb  added the comment:

I have changed the PR accordingly.

Am Mi., 6. Nov. 2019 um 16:36 Uhr schrieb Vinay Sajip :
>
>
> Vinay Sajip  added the comment:
>
> > Would you consider it more acceptable to just turn
> them into class level attributes of BaseRotatingHandler instead of
> setting them in init?
>
> Yes, that would be better.
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue38716>
> ___

--

___
Python tracker 
<https://bugs.python.org/issue38716>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39826] logging HTTPHandler does not support proxy

[lorb]

New submission from lorb :

The HTTPHandler does not support using a proxy. It would be necessary to 
subclass it and reimplement `emit` to enable passing in proxy settings.
Adding a hook to make it easy to customize the connection used would solve this.

--
components: Library (Lib)
messages: 363181
nosy: lorb
priority: normal
severity: normal
status: open
title: logging HTTPHandler does not support proxy
type: enhancement

___
Python tracker 
<https://bugs.python.org/issue39826>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39826] logging HTTPHandler does not support proxy

[lorb]

Change by lorb :


--
keywords: +patch
pull_requests: +18099
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18745

___
Python tracker 
<https://bugs.python.org/issue39826>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41906] logging.config.dictConfig does not work with callable filters

[lorb]

lorb  added the comment:

I looked into implementing this and it's not entirely clear how it could work. 
The main issue I encountered is how to distinguish between a callable that is a 
factory that takes one argument and a callable that is a filter.

One possible approach I see is to rely on the absence of any other keys in the 
configuration sub-directory. Not entirely happy with that (and have to think 
how to treat factory with optional parameter vs filter with optional parameter).
So this would be assumed to be a filter, if inspection reveals that fltr takes 
an argument:
'myfilter': {
'()': fltr,
}
while this would be assumed to be a factory:
'myfilter': {
'()': fctry,
'bar': 'baz',
}

A different approach that I think would be not optimal is to just call the 
callable with a dummy LogRecord passed ind and see if it returns a boolean or 
callable (or throws).

--
nosy: +lorb

___
Python tracker 
<https://bugs.python.org/issue41906>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com