From: Martin v. L=F6wis [mailto:martin@v.loewis.de]
> __path__[0] cannot be an object originally, because the
> package loader inserts a string, always.
Thinking some more, I'd dispute that "always". The *current*
package loader inserts a string, yes. Under Just's patch,
I think this remains true, as well.
But for a general import hook, it certainly isn't enforced. I
posted a snippet of code which uses Gordon's iu, which works
perfectly but which inserts an object into a package's __path__.
I'm not saying that this isn't bad practice, or even relevant to
the case being discussed, but it's *certainly* true that this
whole area is under-documented and not properly enforced. The
only reference I could find to package structure in the standard
documentation was "[XXX Can't be bothered to spell this out right
now; see the URL http://www.python.org/doc/essays/packages.html
for more details, also about how the module search works from
inside a package.]". That URL points to a document which is
described as "Built-in Package Support in Python 1.5" which
doesn't inspire confidence in its accuracy for current Python...
[Hey, I just noticed that it documents __all__, which wasn't in
Python 1.5, I believe. So maybe it is up to date after all!]
Actually, there's a piece of sample code in that document which
suggests putting platform-specific code into the search path via
dirname =3D __path__[0] # Package's main folder
__path__.insert(0, os.path.join(dirname, "plat-" + platform))
That would result in things like ".../lib/package.zip/plat-win32"
being on __path__. Will Just's code handle this? (I'd check, but
the code doesn't run on Win32 yet. Looking at the code seems to
indicate that it will not handle this...) FWIW, Jim's patch does.
Paul.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4