From: "David Ascher" <DavidA@ActiveState.com> > Skip Montanaro wrote: > > > Just> Are you saying that we should fix all cases where non-strings on > > Just> sys.path cause problems, or are you saying that there's so much > > Just> code out there assuming sys.path contains strings, and that we > > Just> therefore should stick with strings? > > > > Just> Both positions can be defended, and both have their problems. > > > > ... > > > > I think there is a third position: make sys.path magic somehow (but have it > > still (appear to) be a list of strings) so that changes to it affect a > > behind-the-scenes list of objects which is normally used to do path-ish > > stuff. > > 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. > I would it support this kind of code: sys.path = L L.append(...) ? regards.
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