3 ms·

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

by garnet7 17y ago

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 17y ago
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/000398.html 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.
- garnet7 17y ago
  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. :)

by garnet7 17y ago

jnoller 17y ago

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/000398.html 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.

garnet7 17y ago
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. :)