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.
