3 ms·

Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence ar

Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter. Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), that contain some copy/pasteable functions the authors deemed useful as comments (itertools), have documented bugs with copy/pasteable workarounds (csv). Oh, and the way they do exceptions is a mess. Oh, and don't try to read the Python standard libraries source code. It's ugly. No, standard libraries should constrain themselves to providing a good foundation for library designers. (I still like Python, and use it a lot.) (Since you mentioned Go. One thing that I love about Go is that everything interaction with the underlying OS goes through the syscall package. Also, their designer went for more minimalism. And they didn't have to worry about design mistakes they made 25 years ago. Python is old. I'm not a fan of Gos compatibility promise: it means Go 1 will rot away too. But they're in a much better starting position.)

binarycrusader 12y ago
While I'll readily agree that some parts of the standard library are rotten, that's not sufficient justification to say that there shouldn't be one. I should also clarify my expectations about a standard library; to me, a standard library should have all of the basics covered (interaction with the underlying system, I/O, networking, etc.) and anything that benefits from better integration with the runtime (think data types such as those found in python's collections module). If anything, I'd argue that the main problem with Python's standard library is not the library itself, but the lack of more focused curation. Note that I never said that I expect all functionality to be available in a language's standard library; for me personally, Go's standard library has roughly the right balance.
- nostrademons 12y ago
  The other thing that really needs to be in the standard library is protocols & interfaces that will be implemented by a number of userspace libraries. Go benefits immensely from having standard io.Reader and io.Writer types and most people implementing them instead of defining their own. Similarly, most of its web frameworks use http.ResponseWriter and http.Request instead of defining their own. Python's unittest module may be a mess as a test framework, but all the major Python unittest frameworks take a unittest.TestCase, which keeps tests portable among the different systems. The worst case is exemplified by pre-STL C++, which didn't even have a string type in the stdlib. As a result, every project and library wrote their own, which meant that you basically had to choose a C++ ecosystem and develop for it rather than write libraries that are portable across multiple C++ projects.
  - the_why_of_y 12y ago
    ... and a sufficiently large C++ application would use 10 different string classes in various parts of it, likely with different text encodings too, with lots of fun converting between them. Even a crappy UTF-16 based String like Java's is better than such a mess.
rdtsc 12y ago
I agree about urllib and unittest. However over the last decade I still find Python to be a one of the best "batteries included" language/platform. That is not small thing either. It allows getting started easier, which in turns gets more people to use it. Here is a list of modules I used and was happy there were in stdlib: socket, shelve, cPickle, tarfile, urllib[2], Tkinter, time, ctypes, subprocess, asyncore, json, SimpleXMLRPCServer, wave (sorry, I did use it many time ;-) ), timeit, syslog and many others. Most of the time I was happy to find them there.
apendleton 12y ago
It all depends what you're using it for. If I'm writing code that's going to be around awhile and can tolerate some dependencies, I'll totally use, say, requests. But I use urllib2 from the repl all the time, especially if I'm on a machine that isn't mine. The fact that any Mac already has the tools on it to grab some JSON from an API, parse it, and do something useful with it from the command line, without having to download or install anything, is immensely useful, even if the API is a bit suboptimal. The same applies to quick and dirty things I'm shoving into a Gist to share with colleagues. Not all things have to be elegant to be useful. (That said, those kinds of usecases aren't really in Rust's wheelhouse, so I still think in Rust's case having batteries not included is probably the right call.)
- natrius 12y ago
  It's possible to achieve the best of both worlds. We could introduce the concept of a standard distribution instead of a standard library. A release of Python should ship with specific versions of requests, nose, and other packages that have a broad community consensus. Those packages could be individually upgraded later, but every install of Python 2.7.9, for instance, would have requests 2.5.1 or greater installed. That would avoid the stagnation packages see when they enter the standard library, and would maintain the benefits of universal availability. Every language ecosystem should work this way.
ptx 12y ago
What's wrong with the exceptions? I never noticed that problem but agree completely on all your other points. (Especially itertools – why aren't the "recipes" defined in the module?!)
buster 12y ago
In my experience the batteries included is one of the best features of python. The standard library is fine for simple and small scripts, especially in restricted environments without pip or sudo rights. They are a lot of awesome python libs (like requests) but it is awesome to have the stdlib available everywhere and be able to depend on it.
- im3w1l 12y ago
  Pip can install without root. Even if pip is not installed, it can bootstrap itself without root.

binarycrusader 12y ago

While I'll readily agree that some parts of the standard library are rotten, that's not sufficient justification to say that there shouldn't be one. I should also clarify my expectations about a standard library; to me, a standard library should have all of the basics covered (interaction with the underlying system, I/O, networking, etc.) and anything that benefits from better integration with the runtime (think data types such as those found in python's collections module). If anything, I'd argue that the main problem with Python's standard library is not the library itself, but the lack of more focused curation. Note that I never said that I expect all functionality to be available in a language's standard library; for me personally, Go's standard library has roughly the right balance.

nostrademons 12y ago
The other thing that really needs to be in the standard library is protocols & interfaces that will be implemented by a number of userspace libraries. Go benefits immensely from having standard io.Reader and io.Writer types and most people implementing them instead of defining their own. Similarly, most of its web frameworks use http.ResponseWriter and http.Request instead of defining their own. Python's unittest module may be a mess as a test framework, but all the major Python unittest frameworks take a unittest.TestCase, which keeps tests portable among the different systems. The worst case is exemplified by pre-STL C++, which didn't even have a string type in the stdlib. As a result, every project and library wrote their own, which meant that you basically had to choose a C++ ecosystem and develop for it rather than write libraries that are portable across multiple C++ projects.
- the_why_of_y 12y ago
  ... and a sufficiently large C++ application would use 10 different string classes in various parts of it, likely with different text encodings too, with lots of fun converting between them. Even a crappy UTF-16 based String like Java's is better than such a mess.

rdtsc 12y ago

I agree about urllib and unittest. However over the last decade I still find Python to be a one of the best "batteries included" language/platform. That is not small thing either. It allows getting started easier, which in turns gets more people to use it. Here is a list of modules I used and was happy there were in stdlib: socket, shelve, cPickle, tarfile, urllib[2], Tkinter, time, ctypes, subprocess, asyncore, json, SimpleXMLRPCServer, wave (sorry, I did use it many time ;-) ), timeit, syslog and many others. Most of the time I was happy to find them there.

apendleton 12y ago

It all depends what you're using it for. If I'm writing code that's going to be around awhile and can tolerate some dependencies, I'll totally use, say, requests. But I use urllib2 from the repl all the time, especially if I'm on a machine that isn't mine. The fact that any Mac already has the tools on it to grab some JSON from an API, parse it, and do something useful with it from the command line, without having to download or install anything, is immensely useful, even if the API is a bit suboptimal. The same applies to quick and dirty things I'm shoving into a Gist to share with colleagues. Not all things have to be elegant to be useful. (That said, those kinds of usecases aren't really in Rust's wheelhouse, so I still think in Rust's case having batteries not included is probably the right call.)

natrius 12y ago
It's possible to achieve the best of both worlds. We could introduce the concept of a standard distribution instead of a standard library. A release of Python should ship with specific versions of requests, nose, and other packages that have a broad community consensus. Those packages could be individually upgraded later, but every install of Python 2.7.9, for instance, would have requests 2.5.1 or greater installed. That would avoid the stagnation packages see when they enter the standard library, and would maintain the benefits of universal availability. Every language ecosystem should work this way.

ptx 12y ago

What's wrong with the exceptions? I never noticed that problem but agree completely on all your other points. (Especially itertools – why aren't the "recipes" defined in the module?!)

buster 12y ago

In my experience the batteries included is one of the best features of python. The standard library is fine for simple and small scripts, especially in restricted environments without pip or sudo rights. They are a lot of awesome python libs (like requests) but it is awesome to have the stdlib available everywhere and be able to depend on it.

im3w1l 12y ago
Pip can install without root. Even if pip is not installed, it can bootstrap itself without root.