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.
--da
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