[Python-3000] Limitations of "batteries included"

Bill Janssen janssen at parc.com
Sun Aug 26 05:53:33 CEST 2007


> On 8/25/07, Guido van Rossum <guido at python.org> wrote:
> 
> I believe the only reasonable solution is to promote the use of
> package managers, and to let go of the "batteries included" philosophy

It's important to realize that most operating systems (Windows, OS X)
don't really support the use of package managers.  Installers, yes;
package managers, no.  And installers don't do dependencies.  And most
users (and probably most developers) are running one of these
package-manager-less systems.

Even with package managers, installing an external extension is out of
bounds for most users.  Many work for companies where the IT
department controls what can and can't be installed, and the IT
department does the installs.  I do this myself, out of sheer lazyness
-- I don't want to understand the system of dependencies for each
Linux variant and I don't want to work as a sysop, so when I need some
package on some Fedora box that isn't there, I don't fire up "yum";
instead, I call our internal tech support to make it happen.  This
means a turn-around time that varies from an hour to several days.
This can be a killer if you just want to try something out -- the
energy barrier is too high.  So as soon as you require an install of
something, you lose 80% of your potential users.

Though I agree with some of your other points, those about the
fast-moving unstable frameworks, and about the packages that depend on
an external non-Python non-standard resource.  Aside from that,
though, I believe "batteries included" is really effective.  I'd like
to see more API-based work, like the DB-API work, and the WSGI work,
both of which have been very effective.  I'd like to see something
like PyGUI added as a standard UI API, with a default binding for each
platform (GTK+ for Windows and Linux, Cocoa for OS X, Swing for
Jython, HTML5 for Web apps, perhaps a Tk binding for legacy systems,
etc.)  I think a standard image-processing API, perhaps based on PIL,
would be another interesting project.

Bill


More information about the Python-3000 mailing list