[Python-Dev] Integrate BeautifulSoup into stdlib?

Stephen J. Turnbull stephen at xemacs.org
Tue Mar 24 09:04:30 CET 2009


Steve Holden writes:

 > Seems to me that while all this is fine for developers and Python
 > users it's completely unsatisfactory for people who just want to
 > use Python applications.

?  I use lots of Python applications under Mac OS X, MacPorts, Debian,
and Gentoo without looking too closely at what the cat drags in.  In
fact, in many cases I don't even know and don't care that they're
Python apps.  As long as the cat stays in her corner, I'm happy.

 > For them it's much easier if each application comes with all
 > dependencies including the interpreter.  This may seem wasteful,
 > but it removes many of the version compatibility issues that
 > otherwise bog things down.

For that version of the application.  As soon as you start thinking
about version upgrades of the application, the package distribution
problem reappears (in the sense that somebody must manage a whole set
of packages in the application's installed tree, make sure they get
removed at upgrade, deal with multiple concurrent installations so
that beta versions can be tested and compared with one's current
production installation, etc).  This is really the same as the problem
that Python currently faces and solves with the batteries-included
stdlib, just specialized to a particular application.  But those
applications are similarly likely to experience bitrot in their
bundled dependencies, and *some* but not all users will find that
somewhere between annoying and disastrous, just like the
Python-with-stdlib distribution itself.  Degree of each kind of issue
will change, of course, but the issues do remain.

As far as I can *all* of these various solutions have their uses, and
each is going to be strongly favored by some groups of users, and more
or less unacceptable to others.  These preferences may or may not be
correlated with specific apps written in Python.  "Batteries included"
is the status quo for the (C) Python project, and I personally don't
see a strong reason to change that policy until those who favor a
package-manager-based solution have a package manager that satisfies
them!


More information about the Python-Dev mailing list