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. 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.
(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. 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). Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Dec 08 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/