
Evolving the Python standard library - fogus
http://sayspy.blogspot.com/2009/09/evolving-standard-library.html
======
idlewords
I remember one of the biggest hassles to moving to Python from Perl was
figuring out which libraries to use for some common tasks (making an HTTP
request, forking a process, parsing XML). There frequently seemed to be one
library that was heavily documented but deprecated, another one that had
everybody talking but wasn't quite ready, and sometimes a third or fourth of
indeterminate status.

After doing some projects in the language, I began to get a feel for how to
choose among competing libraries, but it made the transition to the language
less fun than it otherwise should have been.

Having a useful, agreed-upon standard library would be a terrific help to
developers moving over from other languages.

------
jnoller
Yes, yes, yes. I'll be sending out an email to the stdlib-sig later today
proposing a logical "breaking out" of the stdlib from "the core". We can offer
a "mega pack" download, but there's various (and all good) reasons to offer a
split core/stdlib download as well.

Not just downloading though: it has to be broken out in source control. We
should have a single, shared stdlib in a logically "split" location for all of
the implementations to leverage. It should contain the minimal number of the
_best_ batteries.

~~~
jnoller
Here's the thread: [http://mail.python.org/pipermail/stdlib-
sig/2009-September/0...](http://mail.python.org/pipermail/stdlib-
sig/2009-September/000398.html)

------
mattj
This is stupid. The thing that makes python so good is that it has a rock-
solid, extensive standard library. I'm all for separating it internally so
it's easier for pypy/jython/ironpython to reuse and contribute, but don't make
us rely on the cheeseshop (full of abandonware and broken code- try finding a
STABLE, production-ready s3 client lib, for example). The standard library
exists as a repo of well designed (mostly) and high quality (especially after
3.0) modules, but it's greatest attribute is that it's maintained as much as
the core language.

Without the stdlib, python is just JavaScript with some extra syntax. Imagine
using java without the stdlib. It's very much part of the language.

~~~
pwmanagerdied
Particularly with 3.0, it's not rock-solid at all. There are a ton of
libraries whose behavior regarding strings vs. bytes is currently
unpredictable and undesirable, and several others that should have been
deprecated in 2.X and removed befor 3.

I _like_ the standard library, but there's a lot of room for improvement.

~~~
garnet7
Keep the standard library and continue to make improvements == good.

Remove it so users can roam the wild countryside to hunt for the bits that
they want == bad.

~~~
jnoller
Yup, that's the point.

~~~
garnet7
I'm sorry, I don't think I understand. Is the plan going to be: keep the
"standard lib" but at the same time remove it from "core"?

If that's the case, then it won't make any difference to end users except that
the Python that they download will consist of 2 pieces next to eachother
instead of one big piece, correct?

That said, I just hope that -- whatever happens -- we still have batteries
included. I'd rather not have to forage around PyPI, python module ratings
websites, and forums just to figure out which module distribution to use (out
of many) for a given requirement. It would be nice if I had the time for that,
but for most module distributions I'd rather let the community as a whole come
to a consensus, and then just use that (a la batteries included).

~~~
jnoller
There will still be batteries included. Brett (the article) was talking about
how to clean it up, my point in this thread
([http://mail.python.org/pipermail/stdlib-
sig/2009-September/0...](http://mail.python.org/pipermail/stdlib-
sig/2009-September/000398.html)) is a break-up which still offers the
batteries (as a single download file - the other downloads are "advanced").

No one wants to get rid of the batteries; we just want to move them so they
are not tightly-coupled with cpython-core (meaning for instance, Jython can
more easily leverage them) and we can fix/clean them up more aggressively.

I completely agree with the foraging around PyPi comment - I hate doing that
too, fundamentally what we all want is a cleaner, best of breed stdlib all of
the implementations can share.

~~~
garnet7
Oh, well, that sounds great then. Thanks for the reply. One thing though: you
mention in your post to the ML, "removing things with low test coverage, poor
docs or things which simply are _not_ the best option". I just hope, along
with that, you have the other side of the coin: liberally bring in new things
which have good test coverage, good docs, and which are a pretty darn good
option. :)

------
tvon
I'd be happy if python just had a package manager.

~~~
garnet7
It's being actively developed right now:
<http://pypi.python.org/pypi/distribute>

