> 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.