[Python-Dev] New Import Hook & New Zip Importer

[Fredrik Lundh]

Paul Moore wrote:

> >    - If a path entry ends in ".zip", replace that entry with
> >      a zipimporter instance. (obviously, the zipimport module
> >      must be available for this to work.)
>=20
> This seems like a gross hack. How do I write a similar hook for
> strings ending in ".tar"? This isn't a YAGNI, it's a design
> constraint which I don't believe is reasonable.

    "Let's make it *really* easy to use zip archives, and reasonably =
easy
    to use other custom importers."

really easy:

    import mymodule

reasonably easy:   =20

    import sys

    # manipulate path as necessary

    for index, path in enumerate(sys.path):
        if isinstance(path, string) and path.endswith(".tar"):
            sys.path[index] =3D tarimporter(path)

    import mymodule, ...

if you think otherwise, please provide use cases.  the implied "there =
will be
a separate category of people who provide hooks and repackage existing
programs without having access to source code for any part of the =
program
or the standard library" case is totally bogus, and so is the "there =
will be
programs that add importers to the path without knowing what they add"
case.

> >import.c changes:
> >    - Allow arbitrary objects on sys.path.
>=20
> I still have reservations about this. Code will break... (if you
> mean "string subclasses", then I feel slightly better about it)

that's not much of an argument: fragile code will only break if *you* =
add
non-string objects to the path in *your* programs.

if you don't want your programs to break, don't break them (or fix the
breakage).

</F>