This manifests in the following way: A package directory containing an __init__.py that is a symlink to /dev/null is treated as a namespace package instead of a regular package.

The Bazel build tool creates many __init__.py files in this way, which is how I even ran into this.

Symlinks to regular files seem fine.

Linking __init__.py to /dev/null is very odd. Do you know bazel does that?

I wanted to ask, Do you know why bazel does that?

One question is why doesn't it just try to `open`, but wants to stat first, when the python principle has always been EAFP.

See associated bug filed against Bazel:

https://github.com/bazelbuild/bazel/issues/1458

As for why Bazel does that, it's related to the sandboxing implementation but I don't know any details beyond that.

Since /dev/null is not a file according to os.path.isfile(), I'm going to close this as not a bug.

And to answer Antti's question, it's because the semantics come from the original C code where EAFP is not pleasant.

Is there a reasonable place to document that __init__.py (and probably source files in general) must be a "regular file" by the Unix definition, and not a device file, socket, etc?

There's probably a place to mention it in the language spec for import and/or importlib.

To be thorough, I looked at non __init__.py source files as well, with erratic results.  And who knows what would happen on other OS's.  So a blanket "must be a regular file" seems reasonable.

$ ls -l b.*
lrwxrwxrwx 1 dgreiman eng 9 Dec  9 16:05 b.py -> /dev/null

$ python2.7 -m b             # Success
$ python2.7 -c 'import b'    # Success
$ python2.7 b.py             # Success

$ python3.5 b.py             # Success
$ python3.5 -m b             # Failure
/opt/python3.5/bin/python3.5: No module named b
$ python3.5 -c 'import b'    # Failure
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'b'

$ uname -a
Linux 53334eb940e6 3.13.0-101-generic #148-Ubuntu SMP Thu Oct 20 22:08:32 UTC 2016 x86_64 GNU/Linux

Those results are expected as passing in a file by path means it's just read by open() and then passed to exec() while the others pass through import itself which has the os.path.isfile() check.

Since this is a change from Python 2.7 I would be willing to look at a patch that loosened things that was fully backwards-compatible, but it would be an enhancement and not a bugfix.

Bazel has been updated to no longer create symlinks to /dev/null

https://github.com/bazelbuild/bazel/issues/1458