Vinay Sajip <vinay_sa...@yahoo.co.uk> added the comment:

> If this behaviour can't be changed for backwards compatibility reasons, then 
> so be it.

It can't be changed for this reason.

> But I think it would be disingenuous to claim it's not a design flaw.

Do you think *I'm* being disingenuous, Mark? I don't mean to be. As well as 
developers from Enthought, who write large, well-tested libraries, logging also 
has to satisfy the newbie who writes a one-off script that probably won't even 
be tested via a test runner. For that use case, logging.debug() and friends 
call basicConfig() under the hood so that simple usage is as easy as possible. 
So the "accidental" configuring of logging only occurs if nothing has 
previously been configured and logging.debug() or similar is called. This is 
documented, as has been mentioned. 

Libraries are not supposed to configure logging except using a NullHandler, and 
this is also documented, but there are numerous authors of libraries that 
ignore that advice. If this causes problems to users of those libraries, that 
is down to the authors of those libraries rather than logging itself, and 
issues should be logged against those libraries. I maintain that calling 
basicConfig() in logging.XXX() is not accidental or a design flaw that crept in 
somehow, but was considered specifically in the context of logging in simple 
cases. This is documented in the PEP:

https://www.python.org/dev/peps/pep-0282/#id30

This PEP was the basis for discussion on python-dev before the logging package 
was accepted into Python.

What guidelines does Enthought provide to its developers for configuring Python 
logging and its usage in libraries and unit tests? If this is public, I would 
be interested to see it. Are there any specific third-party libraries you have 
come across which Enthought uses regularly/repeatedly, which misconfigure 
logging in the way you describe? I would also be curious to know about those.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35530>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to