Thanks for looking at this, Mario, but I'd rather not document this attribute, for the reason stated on the PR when I closed it: "I'd like to avoid documenting this attribute, as it's really meant for internal use by the configuration machinery. I realise that it's named disabled rather than _disabled, which might indicate that it's public, but it isn't meant to be, and the name can't be changed now for compatibility reasons, in case some code somewhere is relying on it! I don't want someone to ask for "disabled" to be explicitly supported in configurations, for instance - I can currently argue that it's not meant to be public, as it isn't documented."
Thanks! I was wondering about it but saw no comment about it, issue or anything in the history. At least we have now this issue :). Would you like that I move this to `_disabled` and have a setter for `disabled` that emits a deprecation warning so we can remove this someday or at least make it more explicit that it should not be used?
As it's not documented, people would come across it by browsing the source. I'd just mention in the source (Logger constructor) that it's for internal use, and leave it at that.
Note that even if not in the standard library I've seen this attributed used and documented quite often. Example: https://docs.python-guide.org/writing/logging/#or-print I would really suggest making it private as mentioned before to make sure this does not happen, but if you still prefer just a comment (as in source comment, not even documentation) I'll go with that.
History
Date
User
Action
Args
2022-04-11 14:59:16
admin
set
github: 81285
2019-05-31 10:26:25
mariocj89
set
messages: +
2019-05-31 10:13:28
vinay.sajip
set
messages: +
2019-05-31 10:00:35
mariocj89
set
messages: +
2019-05-31 09:12:33
vinay.sajip
set
status: open -> closednosy: + vinay.sajipmessages: + resolution: not a bugstage: patch review -> resolved