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

Guido van Rossum guido at python.org
Thu Apr 20 23:04:49 CEST 2006

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/)

More information about the Python-Dev mailing list