[Python-Dev] Another approach for the import mechanism (original) (raw)

Gustavo Niemeyer niemeyer@conectiva.com
Fri, 6 Dec 2002 11:51:38 -0200

Yes, but I don't have to clutter my disk for that.

/usr/lib/python2.2 already exists, doesn't it? That's probably one of the few init.zip we'd ever see, since complete packages would certainly be a majority. OTOH, with the current implementation, the standard library is probably the only compressed package we'll ever see.

That's just my opinion, of course, and I hope to be wrong.

> - Don't have to change path to use compressed packages (at least > not if you want to provide compressed packages, individual > compressed modules or the standard library).

I thought you just explained that I will need to change the path to provide a compressed standard library, to point to a directory that contains an init.zip.

No, I didn't. The compressed library would be in /usr/lib/python2.2, which is already in the path.

> - Don't have to specify the compression type hardcoded.

I don't understand that remark. If I have a zipfile, I surely must install a zipfile hook in your approach also - a .tar.bz2 hook won't be able to load the zipfile, no?

What I mean is:

sys.path = ["/usr/lib/python2.2/stdlib.zip"]

vs.

sys.path = ["/usr/lib/python2.2"]

> - Allows one to ship a package inside a zip file, without asking > the user to change his path, and without hacking the package. > > - Allows one to compress a single file (foobar.py.bz2).

This is really the same issue: If you had a mechanism to import a module from a .py.bz2 file, you could use the same mechanism to import a package (or subpackage) from a .zip file. While I think this might be desirable, I also think it was never the goal of PEP 273 to provide such a facility.

My purpose differs from what is in PEP 273, for sure.

Anyway, I'd just like to expose the idea. If everybody disagrees, we can safely forget it now.

-- Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]