A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-December/030985.html below:

Another approach for the import mechanism

[Python-Dev] Re: Another approach for the import mechanismChermside, Michael mchermside@ingdirect.com
Mon, 9 Dec 2002 08:33:02 -0500
Gustavo Niemeyer writes:
> - 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).
>=20
> - Don't have to specify the compression type hardcoded.
>=20
> - Allows one to ship a package inside a zip file, without asking
>   the user to change his path, and without hacking the package.
>=20
> - Allows one to compress a single file (foobar.py.bz2).
>=20
> I belive that my propose is quite clear now. If there are no
> additional supporters, there's no reason to go on.

I think this proposal would make sense IF compression were an
important goal here. But to me, it isn't. Zip does two things...
it aggregates into a single file (maintaining directory structure)
and it compresses. Of the two, I find the aggregation important
and the compression a mere side effect.

This is why I really don't care much about switching to a different
compression (or aggregation) format -- one standard way to do it
is more useful to me than a BETTER way. It is why I don't care about
compressing a single file. Basically, disk space is cheap, but
effort to keep track of (and distribute) complex file hierarchies
isn't.

> Thanks to everyone who discussed.

And thanks for your contributions too. I don't realize exactly
what I was looking for from .zip until you explained so clearly
the benefits of your proposal.

-- Michael Chermside




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4