"Moore, Paul" <Paul.Moore@atosorigin.com> writes: > > __path__[0] = os.path.join(__path__[0],'package.zip') > > > > package.zip > > Of course, if __path__[0] was originally an object, this would > break... What do you mean with "was originally", and what do you mean with "would break"? __path__[0] cannot be an object originally, because the package loader inserts a string, always. Even if it was a (non-string) object, I can't see how this would break. os.path.join would continue to work if the object is a string subclass, or atleast supports len, __getitem__, and __add__. The result would be a string, which would be converted to a zipimport on the next package contents import. > I think that the objects-on-sys.path issue has now been resolved, > but this probably acts as a reasonable "real world" example of what > needs to be supported. (Unless I've misunderstood things again :-)) I recommend you try the patch, to see how it works in the real world. Regards, Martin
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