[Python-Dev] New and Improved Import Hooks

[Fredrik Lundh]

Guido wrote:

> > > I still think I'd like sys.path to be a real list of real strings =
(not
> > > necessarily representing files or directories though), with a
> > > configurable set of handlers that are given a chance to deal with =
each
> > > string in turn.  (Or was this already rejected?
> >=20
> > I've rejected it.  Does that count?  ;-)
> >=20
> > </F>
>=20
> Why don't you care about the backwards incompatibilities?

hey, I always care about backwards (in)compatibility (and you should
know that by now ;-).  But I've also written tons of code that uses
sys.path in various ways, and probably more different code archivers
than anyone else (Gordon keeps working on the same installer all the
time; I usually invent a new one for each new project), and I'm not
convinced that there are any real incompatibilities...

Let's list a couple of use cases (covering roughly 100.00% of the
code I've studied over the years):

1) code that doesn't use sys.path directly

this is the vast majority of all code.  no breakage at all, even if =
Python
itself would add non-stringy things.

2) code that appends/inserts/removes things from sys.path

quite common.  won't break if PYTHONPATH isn't changed.  very unlikely
to break if ZIP files are added to PYTHONPATH.  unlikely to break if =
string-
compatible objects are added to sys.path.  and in most normal use cases
(insert/append directories), unlikely to break if non-string objects are
added to sys.path.

3) code that uses sys.path to search for things in the file system, but
doesn't expect all items to exist and/or be valid directories.

relatively uncommon.  won't break if PYTHONPATH isn't changed.  unlikely
to break if string-compatible objects are added to sys.path.  likely to =
break
if non-string objects are added to sys.path.

4) code that assumes that everything on sys.path points to a directory

not that common.  won't break if PYTHONPATH isn't changed.  might break
if ZIP files are added to the path (whether they're real strings, string =
sub-
types, or non-string objects).  likely to break if non-string objects =
are added
to sys.path.

5) code that assumes that everything on sys.path points to an existing =
directory

already broken (but I've fixed such bugs more than once, also in my own =
code...).
won't break if PYTHONPATH isn't changed.  will break if ZIP files are =
added to the
path (no matter how they're represented; see above).

:::

summing up, I don't think *any* code will break after an upgrade, as =
long
as PYTHONPATH isn't modified.

some code may break if ZIP-files are added to PYTHONPATH or sys.path
(no matter how they're represented), and some more code may break if
non-string objects are added to sys.path.

But as long as Python itself won't add non-stringy objects by magic, =
that's
not really a problem.

</F>