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:
...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/
I'm working from a link I was given when I started asking how namespaces/modules worked and why they weren't working for me. The answer I got was "first, you're probably doing it wrong if you need namespaces, and here's why <url>. second, here's the answer to your problem."
I'm trying to locate the article and I'll include it once I've found it. That's what I based my comment on.
> 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:
...where both some_path/ and other_path/ are in $PYTHONPATH. If you have some Python code that does this: ...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.