Why things should be in Python's standard library

September 23, 2010

There's another advantage of having things in the standard library: if they're in the standard library, they'll get used. This is what you want when the standard library module is the right solution to its problem (and a terrible idea if the module is a bad solution), especially when there are worse alternatives.

There are a lot of problems that have a few good solutions and a lot of bad ones; a classical example is parsing XML (using regular expressions versus a real parser). If one of the good solutions is not in the standard library but you can build a bad solution from other standard library bits, it's pretty much guaranteed that lots of people will build versions of the bad solution; people solve a lot of their problems using whatever tools the standard library gives them.

(Some of the people will start down the bad road because they don't know any better and don't realize how much pain they're getting themselves into. Some will do it because it works well enough for their current needs and it is the fast way to solve their problem.)

For a sufficiently common problem, especially if the wrong ways are sufficiently unproductive (or are sufficiently bad ideas), the conclusion is that you want an implementation of the right way to be in the standard library so that people will use it instead of slapping together yet another cringe inducing implementation of a bad solution.

(If this is an obscure problem, well, you can't put everything in the standard library.)

One short way of putting this is that the standard library should have good implementations of common things that it is (too) easy to get wrong.

(By the way, it does no good to say that people should not be so foolish as to tackle these problems the wrong way. This may be technically correct, but it does not solve the social problem of getting people to produce good code.)

Sidebar: the drawback of complexity

I cheated a bit. It's not enough that the standard library module be the right way to solve its problem, because that's not sufficient by itself to get people to use it over the alternatives. It must be the easiest way to solve its problem (or at least look like it). There are two sides to this: the amount of code you have to write with and without the module, and the amount of mental work you need to do in order to put together a solution, ie the module's complexity.

The module can usually win on the amount of code you have to write (if it can't, it has serious problems). Some standard library modules have not been too successful on the complexity front, though.

(Examples can help. Especially examples of doing simple things.)

Written on 23 September 2010.
« The mysteries of video cards for Linux
Frames were never necessary for menus and tables of contents »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Sep 23 00:07:35 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.