All I have to add is that I am appalled that people actually write `from
foo import __init__`, and I am sorry that we left this hole open when
implementing packages. I don't know what's the best way forward now that
the cat is out of the bag, but deprecation seems a reasonable thing to do.
As for how people can check whether a package is a namespace package, there
are many other ways to check for that without attempting to import
`__init__` from it.
On Thu, Dec 10, 2020 at 9:46 AM Gregory Szorc
On Thu, Dec 10, 2020 at 5:47 AM Serhiy Storchaka
wrote: 09.12.20 22:39, Steven D'Aprano пише:
On Wed, Dec 09, 2020 at 01:56:01PM +0200, Serhiy Storchaka wrote:
Thank you for good explanation of the problem.
I'm sorry Serhiy, I disagree that this has been a "good explanation of the problem".
Gregory has not identified any actual bugs caused by this. The only problem he has identified is that doing this will lead to two separate module objects from the same file, but as MAL points out, people can do this intentionally. Gregory hasn't identified any cases where people are doing this accidentally and having bugs in their code because of that. He just assumes that they are.
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
And this happens not only with classes. Modules foo and foo.__init__ has similar content, but their values are not the same. Some values can be identical, some are identical on some Python implementations and non-identical on others, some are equal but non-identical, some are not even equal.
Gregory has still not been 100% clear that he is only talking about package __init__.py files. I am pretty sure that is what he means, but the only precise statement he has made is the code
'__init__' in fullname.split('.')
but that will effect non-package files:
__init__.py # not a package, not a special name
and also packages with unusual but legal names:
package/subpackage/__init__/things/stuff.py
Since __init__ is a special name and directory __init__ conflicts with file __init__.py, I do not think this is good idea. I am not even sure that it works. I do not think this is necessary, but just for the case it may be better to forbid intermediate __init__ components as well. But it depends on the implementation. What will look more natural.
I'd also like to note that the various importers in the standard library are inconsistent in their handling of "__init__" as the trailing component (`fullname.split(".")`) of a module name. Specifically, the builtin, frozen, and zip importers will only match exact name matches. And since the canonical module name is "foo" instead of "foo.__init__", requests for "foo.__init__" will work with PathFinder but none of the other meta path finders in the standard library.
I would argue that module names should be treated identically, regardless of the importer used. But this isn't the case and this is why I feel like the behavior of PathFinder is a bug that shipped.
I'll also note that this behavior/bug affects the ability to distribute Python applications seamlessly. With the current behavior of allowing ".__init__" as the module name suffix, any Python code relying on this behavior will be difficult to package if using an application distribution tool that doesn't use PathFinder. This includes PyOxidizer, py2exe, PyInstaller, and various other tools which rely on the zip importer or custom importers.
So one can make the argument that this one-off behavior of PathFinder undermines the ability to easily distribute Python applications and that in turn undermines the value of Python in the larger ecosystem. My opinion is the harm inflicted by dropping support for "__init__" in module names will be more than compensated by long-term benefits of enabling turnkey Python application distribution. But that's my personal take and I have no solid evidence to justify that claim. The evidence that PathFinder is inconsistent with other meta path finders in the standard library is irrefutable, however. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/CIQP3Y... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...