Evolving the Python standard library | Hacker News Reader

Evolving the Python standard library

sayspy.blogspot.com

26 pointsfogus14 comments

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.

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.

Here's the thread: http://mail.python.org/pipermail/stdlib-sig/2009-September/0...

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.

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.

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.

Yup, that's the point.

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

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

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. :)

Python is just JS with extra syntax? The languages have very different object and meta-object/overloading models, as well as other divergent features: JavaScript can mutate closures, for example.

I agree, though, that a stdlib should be part of the core language. Not having a serious standard library has hurt the Scheme community a great deal, I think.

What's being proposed is trimming it of less useful libraries (and ones without maintainers, low test coverage, etc). No one wants it to "just go away".

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

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

Reply on news.ycombinator.com