WPS412: Improve rationale

[Dreamsorcerer]

I'm still not understanding the rationale for this violation, and was just wondering if you could explain it to me better.

Is it not standard practice (and Pythonic) to have a library which can be imported and used like:

import asyncio
asyncio.create_task()
asyncio.run()

This requires some logic, even it's only import statements. Are you proposing that this would be a better design?

from asyncio.tasks import create_task
from asyncio.runners import run
create_task()
run()

The first approach looks better to me, but contradicts this rule. I'm just trying to understand the reasoning for this.

[sobolevn]

The main idea is that I should not tweak your imports in your project.
Why? Because it is hard to read and refactor things. The same function can be theoretically imported from mypackage and mypackage.mymodule.

And with libraries it is totally fine to tweak imports. Libraries are going to use --i-dont-controll-code anyway.

Are you proposing that this would be a better design?

Well, this is a hard topic. And it really depends. I use this style for almost all my libraries. But, I can imagine libs where this design is not suitable (like attrs, etc).

[Dreamsorcerer]

And with libraries it is totally fine to tweak imports. Libraries are going to use --i-dont-controll-code anyway.

Yes, but the rationale sounds like it skips this check due to backwards-compatibility concerns, suggesting that you would still rather enforce it if it was a new library.

So, it sounds to me like it should be reasonable to allow this, as long as the module is designed such that all external imports are meant to use the parent namespace, and not use any submodules.

e.g. The asyncio example I've shown, appears to use a bunch of submodules to help keep the internal code maintainable, but developers should always import asyncio. I don't think I've ever seen someone import from the submodules directly (and they don't appear anywhere in the documentation).

[Dreamsorcerer]

I bring this up because I have a module _localdev.py in my project which has grown in size. So, following the other rules I have broken this down into smaller files by putting it all under a new directory. But, I am still only exporting 2-3 functions to the outer code. So, like the asyncio example, it seems reasonable for me to export those functions directly in __init__.py and have the outer code never even be aware of the submodules here, as they are used purely to improve maintenance internally.