On 10.12.2020 14:18, Serhiy Storchaka wrote:
> 08.12.20 22:14, M.-A. Lemburg пише:
>> On 08.12.2020 20:47, Gregory Szorc wrote:
>>> Anyway, I was encouraged by Brett Cannon to email this list to assess the
>>> appetite for introducing a backwards incompatible change to this behavior.
>>> So
>>> here's my strawman/hardline proposal:
>>>
>>> 1. 3.10 introduces a DeprecationWarning for "__init__" appearing as any
>>> module
>>> part component (`"__init__" in fullname.split(".")`).
>>> 2. Some future release (I'm unsure which) turns it into a hard error.
>>
>> -1 on this proposal. We don't want to needlessly break code just because
>> they use a feature of the existing implementation, which has been around
>> for decades.
>
> This feature has some bad side effects. Also, it does not look like this
> feature was added intentionally, otherwise we would handle these side
> effects.
I know that it's not intentional, but people are obviously using it
and this code would break.
>> Moreover, if you use namespace packages, a module __init__.py does not
>> have to exist in the directory, so importing pkg.__init__ is a way
>> to test for such a case.
>
> Why do you need to test such a case? And are there other ways, without
> such side effects?
>
> I never seen a code
>
> try:
> import mypackage.__init__
> except ImportError:
> # do something
> else:
> # do something else
>
> (But on other hand, I did not see importing from __init__ as well before
> OP opened the issue.)
:-)
Just wanted to point out that the situation is a bit different now
that we have namespace packages, compared to the days when packages
were added to Python.
Note that the issue of importing the same module more than once
also shows up when you have your PYTHONPATH incorrectly set up,
e.g. pointing inside a package as well as to the top-level.
>>> (A less aggressive proposal would be to normalize "__init__" in module
>>> names to
>>> something more reasonable - maybe stripping trailing ".__init__" from module
>>> names. But I'll start by proposing the stricter solution.)
>>
>> -0 on this, since it may break code. If done, Python should issue
>> a warning to flag the issue.
>
> Actually, making package.__init__ an alias of package would mitigate the
> issue. But I am not sure we need such feature.
I think we could do something to mitigate the negative effects
(running the __init__.py code twice) by having the second module
object use the same dict as the package module, but there's an issue:
the "__init__.py" will actually show up in the package name
and code could be using this.
Is this worth the trouble ? I doubt it. It's probably better to
add a warning to make users aware of the possible issue and have
them fix it.
>> Third solution: leave things as they are and document it.
>>
>> +1 on this one, since it's been like this for ages (going way back to
>> the Python 1.x days).
>
> It was my first reaction. Just say "Don't do this". But many people does
> not read documentation and does not use linters, so it makes sense to
> add a warning which can force them to read explanation in the
> documentation (or at least ask a question on forum).
Agreed.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Dec 10 2020)
>>> Python Projects, Coaching and Support ... https://www.egenix.com/
>>> Python Product Development ... https://consulting.egenix.com/
________________________________________________________________________
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/
_______________________________________________
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/DO3EPP5FMETIRH3Q5IMCXG3EQZSJBQ6B/
Code of Conduct: http://python.org/psf/codeofconduct/
