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 <gregory.sz...@gmail.com>
wrote:
> On Thu, Dec 10, 2020 at 5:47 AM Serhiy Storchaka <storch...@gmail.com>
> 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-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/CIQP3YP6TWPLUIYDUXNMNRPD34XYYDX2/
> 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-change-the-world/>
_______________________________________________
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/HBT3M5STQIHSYNRPJNE7AVZJCXRUYYTX/
Code of Conduct: http://python.org/psf/codeofconduct/
