[Python-Dev] New and Improved Import Hooks

[David Ascher]

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