On Thu, Dec 10, 2020 at 03:46:37PM +0200, Serhiy Storchaka wrote:
Maybe it is just me, because I read the original issue. But Gregory's message looks to me well organized and answering questions that were asked before and possible new questions.
Here is an example. File "foo/__init__.py" contains "class A: pass".
from foo.__init__ import A import foo isinstance(A(), foo.A) False
Yes yes, I get that, and I got that from Gregory's first post. I understand the consequences. They are the same consequences as from:
import fractions del sys.modules['fractions'] import fractions as frac isinstance(fractions.Fraction(), frac.Fraction) False
Should we make a warning for this too? That's not a rhetorical question. Your argument applies here too: some people don't read the docs, and they might not realise that they have two distinct module objects from the same .py file, so we should force them to read the docs with a warning or an exception. There are other ways you can get this same effect. Should we have warnings for them all? import spam ImportWarning: spam.py is a hard link to eggs.py and we want to force you to read the docs to learn why this is a bad idea. I don't think we should scold users with warnings and errors, breaking their code, because it *might* be bad, or because the code looks weird. Weird code is not illegal. If somebody can prove that this is a common source of real program bugs, not just a potential source of bugs, then we should consider breaking backwards compatibility. But until there are proven real-world bugs coming from this feature, we should not touch it. Referring to a subpackage with an unusual name: package/__init__/__init__.py
Since __init__ is a special name and directory __init__ conflicts with file __init__.py, I do not think this is good idea.
There is no conflict between a directory called "__init__" and a file called "__init__.py". Both can exist in modern file systems. $ ls -d __init__* __init__ __init__.py I agree that it looks ugly and is weird, but we should not prohibit code just because it looks weird.
I am not even sure that it works.
Seems to work fine when I tried it: $ cat package/__init__.py print("importing toplevel package __init__.py") $ cat package/__init__/__init__.py print("importing subpackage __init__/__init__.py") And importing them: >>> import package.__init__ importing toplevel package __init__.py importing subpackage __init__/__init__.py If it didn't work, I would call that a bug. "__init__.py" module files are special; *directories* called "__init__" are not special, they're just an ordinary name. So if we change any behaviour, it should only apply to "package/__init__.py" files, not arbitrary path components "__init__". -- Steve