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

Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___ P

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

Vinay Sajip added the comment: New changeset 519cb8772a9745b1c7d8218cabcd2f96ceda4d62 by Vinay Sajip (l0rb) in branch 'master': bpo-38716: stop rotating handlers from setting inherited namer and rotator to None (GH-17072) https://github.com/python/cpython/commit/519cb8772a9745b1c7d8218cabcd2

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

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

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

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

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

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

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

Vinay Sajip added the comment: They can be methods, but don't need to be. In my example, I showed how you can set the namer and rotator attributes to methods which do have access to self. I don't want to encourage the idea that namer and rotator *have* to be methods that have to be overridde

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

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 han

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

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__(

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

Change by lorb : -- keywords: +patch pull_requests: +16581 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17072 ___ Python tracker ___ ___

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

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 fir