(Rereporting from https://github.com/indygreg/PyOxidizer/issues/317.)

$ mkdir foo
$ cat > foo/__init__.py <<EOF
> test = True
> EOF
$ cat > foo/bar.py <<EOF
> from .__init__ import test
> EOF
$ 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 foo.bar
>>> import sys
>>> sys.modules['foo']
<module 'foo' from '/home/gps/tmp/pyinit-test/foo/__init__.py'>
>>> sys.modules['foo.__init__']
<module 'foo.__init__' from '/home/gps/tmp/pyinit-test/foo/__init__.py'>

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 `__init__.py[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.