Hacker News Reader

Comment by mattj | Hacker News Reader

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.

View on HN

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

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.

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

Reply on news.ycombinator.com