[Python-Dev] New and Improved Import Hooks

[Just van Rossum]

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