This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author indygreg
Recipients brett.cannon, eric.snow, indygreg, ncoghlan, serhiy.storchaka
Date 2020-12-04.18:31:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1607106668.74.0.188156502062.issue42564@roundup.psfhosted.org>
In-reply-to
Content
I worked around this in PyOxidizer by stripping a trailing `.__init__` from module names when resolving the indexed resource data. This allows the import to work since it can find the data now, but it also preserves the double module object, which isn't ideal IMO.

My preferred solution would be to either ban `__init__` in module name components or strip trailing `.__init__` from the name in `find_spec()`, effectively normalizing it away. Either of these would be backwards incompatible. Could either of these be considered for 3.10?

It's worth noting that `__init__` could potentially occur in the interior of the module name. e.g. `foo.__init__.bar`. This would require filenames like `foo/__init__/bar.py`. I wouldn't be surprised if this exists somewhere in the wild.
History
Date User Action Args
2020-12-04 18:31:08indygregsetrecipients: + indygreg, brett.cannon, ncoghlan, eric.snow, serhiy.storchaka
2020-12-04 18:31:08indygregsetmessageid: <1607106668.74.0.188156502062.issue42564@roundup.psfhosted.org>
2020-12-04 18:31:08indygreglinkissue42564 messages
2020-12-04 18:31:07indygregcreate