4 ms·

Evolving the Python standard library

26 points by fogus 17y ago

jnoller 17y ago
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 17y ago
  Here's the thread: http://mail.python.org/pipermail/stdlib-sig/2009-September/000398.html http://mail.python.org/pipermail/stdlib-sig/2009-September/0...
idlewords 17y ago
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.
mattj 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      Yup, that's the point.
      - 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.
tvon 17y ago
I'd be happy if python just had a package manager.
- garnet7 17y ago
  It's being actively developed right now: http://pypi.python.org/pypi/distribute http://pypi.python.org/pypi/distribute

26 points by fogus 17y ago

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 17y ago
Here's the thread: http://mail.python.org/pipermail/stdlib-sig/2009-September/000398.html http://mail.python.org/pipermail/stdlib-sig/2009-September/0...

idlewords 17y ago

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.

mattj 17y ago

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 17y ago
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 17y ago
  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 17y ago
    Yup, that's the point.
    - 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.

tvon 17y ago

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

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