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/