[Python-Dev] New and Improved Import Hooks

[Samuele Pedroni]

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.