David Ascher wrote: > I'm not sure I understand Skip's proposal, which may be the same as the > following, which strives for backwards compatibility: > > - Define an alternative path which can have non-strings on it, and define > sys.path to be a "view" of the string elements in this superpath. > > IOW: > > assert sys.path == ['a', 'b', 'c'] > assert sys.superpath == ['a', 'b', 'c'] > sys.superpath.insert(0, CodeGenerator()) > assert sys.superpath == [<CodeGenerator instance>, 'a', 'b', 'c'] > assert sys.path == ['a', 'b', 'c'] > sys.path.insert(0, 'foo') > assert sys.superpath == ['foo', <CodeGenerator instance>, 'a', 'b', 'c'] > assert sys.path == ['foo', 'a', 'b', 'c'] > > the superpath is used in by the import mechanism, and modifications to > sys.path propagate back. > > It's not ideal, but I think it's backwards compatible. How is this different (besides being more complex <wink>) from making import hooks string subclasses? (I'd still like to see more examples of code breaking if a sys.path item isn't a string. Not that I don't believe it, but I'd like to get an impression of the severeness of the damage.) Just
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