[Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

[Guido van Rossum]

On 4/20/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> 1. don't load packages out of .zip files. It's not that bad if
>    software on the user's disk occupies multiple files, as long as
>    there is a convenient way to get rid of them at once.
>    Many problems go away if you just say no to zipimport.

You forget that importing from a zip file is often much faster than
importing from the filesystem. That's why zipimport was added in the
first place.

> 2. standardize on file names, not API. If I want to deploy
>    read-only data files, I put them into /usr/share. If I need
>    read-write files, I put them into /var.

What about Windows?

Putting data files in the same directory as source files solves a lot
of problems of making the data follow the source no matter how/where
it is installed (or if it's not installed at all, like when running
code straight out of svn).

Anyway, perhaps it's a matter of choice. It's clear to me that many
developers prefer to do it this way. You don't. This is an area that
has enough external constraints that I'm uncomfortable telling
developers they can't do it that way. A standard API to access
resources by name (with perhaps a registry for defining additional
ways to find them) makes a lot of sense to me, and I don't think we're
exactly inventing something novel here.

[...]

> Some libraries (not necessarily in Python) have gone the path of
> providing a "unified" API for all kinds of file stream access,
> e.g. in KDE, any tool can open files over many protocols, without
> the storage being mounted locally. I consider this approach
> flawed: once I leave the realm of KDE programs, this all stops
> working. It is the operating system's job to provide unified
> access to storage, not the programming language's or the job
> of a library.

I don't see it that way. All operating system access is mediated via
the Python library anyway; and in many cases the Python library
provides additional abstractions over what the operating system
natively provides (e.g. many APIs in the os and os.path modules). You
can't blame KDE for providing mechanisms that only work in the KDE
world. It's fine for Python to provide Python-specific solutions for
issues that have no cross-platform native solution.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)