On Tue, Dec 08, 2020 at 03:07:48PM -0800, Gregory Szorc wrote:
> We're talking about "__init__" being the exact name of a module component.
> `"__init__" in fullname.split(".")`, as I wrote in my initial email.
I'm sorry, you've just added more confusion to me, rather than less :-(
What's a module component? Do you mean a directory name? If I have a
package:
mypackage/subpackage/__init__/stuff/things/spam.py
never mind that this is an unusual naming convention, but according to
your test given above, that means that importing
mypackage.subpackage.__init__.stuff.things.spam
should be treated according to your proposal.
I *thought* you meant only modules called literally "__init__.py" (or
equivalent .pyc etc), and only if they are part of a package, but your
test above suggests that this is not the case.
For example, if I have a non-package module called "__init__.py" with no
package structure, what happens? Right now I can import that easily, and
because there is no package structure, it's just a module with an
unusual name.
So that's two cases that your "in fullname.split" test above seems to
mishandle:
- bare modules (not part of a package) called "__init__";
- (sub)packages called "__init__", corresponding to a directory called
"__init__".
There may be other cases.
I think your proposal needs to be more specific about *exactly* what
cases you are handling. I think it is *only* the case that you have a
package and the __init__.py file inside the package is imported
directly, but your test for that case is too broad.
(Modulo file extensions of course.)
> "__init__ as a substring - as weird as that may be - should be allowed.
> This is because it is only the exact "__init__" filename that is treated
> specially by the filename resolver.
Okay, that's what I thought you meant, but your insistence on this test:
"__init__" in fullname.split(".")
[Me]
> > I think that you would need to demonstrate that:
> >
> > (1) people are inadvertly importing "__init__", not realising the
> > consequences;
> >
>
> > (2) leading to bugs in their code;
> >
> > (3) that this happens *more often* than people intentionally and
> > knowingly importing "__init__";
> >
> > (4) and that there is a work-around for those intentionally importing
> > "__init__".
> >
[Gregory]
> I can't speak for the people practicing this pattern because I'm not one of
> them. However, I'm willing to bet a lot of them are either cargo culting
> the practice or thinking "oh, this __init__.py file exists, '__init__' must
> be the module name." The importer/code works and they run with it.
So do you have any examples of *actual* bugs caused by this feature, or
is this is a hypothetical problem?
> I'm also willing to wager that people engaged in this practice (who
> apparently don't fully understand how the importer works otherwise they
> wouldn't be using "__init__" in module names) don't realize that this
> practice results in multiple module objects. I'm willing to wager that a
> subset of these people have seen weird bugs or undesired behavior due to
> the existence of multiple module objects (e.g. 2 instances of a supposed
> module singleton).
>
> I wish I could find stronger evidence here, but I don't have anything
> concrete, just a GitHub search showing code in the wild, likely authored by
> people who aren't Python experts.
Or maybe they are experts who are doing exactly what they need to do,
e.g. see MAL's comment about using the existence of an __init__ module
to distinguish a namespace package from a regular package.
As the person proposing a backwards-compatibility breaking change, the
onus is on you (or somebody supporting your proposal) to demonstrate
that breaking people's code, even with just a warning, is *less bad*
than the status quo.
"I feel, I expect, I would wager" etc is not evidence for this being an
actual genuine problem that needs fixing. I would need to see more than
just your gut feeling to support changing this behaviour. As MAL says,
this behaviour apparently goes back to Python 1.5 days and the number of
bug reports caused by it is approximately zero.
I agree with you that importing __init__ directly *feels* weird, it's a
code smell, but then I feel the same about people who call dunders
directly, and even referring to __doc__ directly feels weird. But that
doesn't mean it is broken.
--
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/YPQEEVNL4W47GU2ONQP45J5NL2PPGQFK/
Code of Conduct: http://python.org/psf/codeofconduct/
