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 indygreg
Date 2020-12-04.02:11:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
(Rereporting from

$ mkdir foo
$ cat > foo/ <<EOF
> test = True
$ cat > foo/ <<EOF
> from .__init__ import test
$ python3.9
Python 3.9.0 (default, Nov  1 2020, 22:40:00)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import
>>> import sys
>>> sys.modules['foo']
<module 'foo' from '/home/gps/tmp/pyinit-test/foo/'>
>>> sys.modules['foo.__init__']
<module 'foo.__init__' from '/home/gps/tmp/pyinit-test/foo/'>

I am surprised that `from .__init__` even works, as `__init__` isn't a valid module name.

What appears to be happening is the path based importer doesn't recognize the `__init__` as special and it falls back to its regular file probing technique to locate a module derive from the path. It finds the `[c]` file and imports it.

A consequence of this is that the explicit `__init__` import/module exists as a separate module object under `sys.modules`. So you can effectively have the same file imported as 2 module objects living under 2 names. This could of course result in subtle software bugs, like module-level variables not updating when you expect them to. (This could also be a feature for code relying on this behavior, of course.)

I only attempted to reproduce with 3.9. But this behavior has likely existed for years.
Date User Action Args
2020-12-04 02:11:52indygregsetrecipients: + indygreg
2020-12-04 02:11:52indygregsetmessageid: <>
2020-12-04 02:11:52indygreglinkissue42564 messages
2020-12-04 02:11:48indygregcreate