The problem with Python namespaces

I'm somewhat confused by this article. It describes the problem like this:

> Those dragons are such: you have two paths inside sys.path that contain similar code. Such as I do with all of the Domain51 code. Package one has foo as a module while package two contains bar. The assumption would be that Python acts like most other languages and would exhaust it's sys.path trying to find both packages, but that's not the case. It'll get to the first one, then pretend the second doesn't exist.

...but I'm certain Python can "import foo; import bar" without issue.

Poking at the sample repository the article links to, it seems the problem is something more like this:

    +- some_path/
    |  |
    |  +- foo/
    |     |
    |     +- __init__.py
    |     +- fred.py
    |
    +- other_path/
       |
       +- foo/
          |
          +- __init__.py
          +- barney.py

...where both some_path/ and other_path/ are in $PYTHONPATH. If you have some Python code that does this:

    from foo import fred
    from foo import barney

...then the second line will raise ImportError. The first line causes a mapping "foo" -> "some_path/foo/" to be added to the module name cache, so on the second line it tries to import "barney" from "some_path/foo/" and fails.

I'm not sure what pkg_resources has to do with anything, but I think Stop Doing That is a reasonable response.

This seems to rely on pkg_resources, which isn't a standard module but rather part of setuptools. There's a rejected PEP for including it in the standard library: http://www.python.org/dev/peps/pep-0365/

The comments seem to address his concerns, but I just had to call this out:

"As you don't see this hardly anywhere in Python because Pythonistas feel that namespaces are a bad idea..."

From The Zen of Python: "Namespaces are one honking great idea -- let's do more of those!"