Hey there! I'm curious to know what this group thinks about the implicit design of many Python libraries, both core and open source. What I mean by "implicit design" is when an interface of library is established and initialised at module’s level rather than explicitly encapsulated in classes. Couple of the examples: 1. logging 2. asyncio Both of the libraries (by design) allow only 1 framework per process, which can be limiting. Although it's easier to hack the logging library to obtain an independent hierarchy with separate root node, it's a bit more challenging to obtain a separate asyncio loop. Allowing users to instantiate a fresh instance of framework would be advantageous in various ways: 1. "Explicit is better than implicit" - easier to understand, inherit, and edit. 2. The ability to instantiate multiple framework nodes leads in a modifiable, therefore easier to comprehend workflow. For example, having separate logging and asyncio on a thread would provide for greater design freedom. 3. Code reusability. When I am looking for code (to avoid reinventing the wheel), whenever I find initialisations at the module level it is a signal that the code is not easily reusable, and I continue my search. I'll return to such code as a last option. I think such design is reasonable for “end result” products, that are not at the risk of becoming standard dependencies, but is it a good idea to continue this standard practice for "building block" libraries? It is not a complaint in and of itself (maybe a bit), but rather an attempt to spark a discussion about whether more modular and explicitly contained architecture would help the Python community the most in the long run.