His complaints are essentially: 1. The 'sys' and 'os' modules require too much typing and aren't 'beautiful' enough. 2. 'Requests' isn't stdlib. (because obviously) 3. Rargh time zones are annoying. (not python's fault that we, as people, split time into arbitrary 'zones') 4. I prefer a different testing module.
And his solutions are: 1. To use a wrapper that requires a little less typing. 2. To complain about it. 3. To use a third party lib that 'solves' the issue because it gets updated more frequently. 4. To use a different testing module.
I don't see how any of this means that Python's stdlib has 'dead batteries.' What a garbage article.
On a side note, I feel this is a terrible idea:
>The proposal introduces a provisional stage that allows packages to go into the standard library without enforcing the hard guarantees of backwards compatibility and API stability that previously made standard library inclusion undesirable.
The standard lib should be made of things that are rock solid. You don't build a house on unreliable-but-so-fun-to-use materials, nor should Python mess with stability so that blog writers bitch less.
Sidenote: the json module lives in the stdlib now but started out as a third party module, simplejson. Not sure what that says vis-a-vis the author's fuzzy thesis.
Still, the only thing I use with any frequency that is an outright replacement for standard library functionality is requests and beautifulsoup. Well, if you don't include ipython, which is an absolute necessity.
os
sys
logging
os.path
re
subprocess
datetime
json
pickle
itertools
urllib2
signal
traceback
socket
To refer back to the "old batteries" argument, the included batteries may be the old lead acid type, but they're dependable in a lot of cases where newer lithium ion batteries would rather catch fire.
I just remember that datetime is the package, datetime.datetime is the class, and datetime.datetime.now() is a @classmethod that returns instances of that class. I do kinda wish it was datetime.now() for the constructor instead.
Or do you find Python's argument parsing to be especially notable for some reason?
* sys.argv
* argparse
* optparse
* getopt
There are, of course, additional third party modules (like opster) that also handle arguments.
optparse is deprecated (kept around for obvious backward-compat reasons)
getopt is just a different API for people who feel more comfortable with C's getopt API and don't want to learn something else
argparse is the CLI option parser for the future.
tl;dr: There is one way to parse command line arguments: sys.argv. But there are a few abstractions of doing that available in the stdlib.
The title is link bait. The "batteries" work fine - some are venerable, but they are well tested and documented.
The author ignores stellar parts of the standard library such as: collections, itertools, contextlib, functools, itertools, sqlite3, hashlib, struct, json, elementtree, etc.
Essentially, the author is bashing the entire standard library because the urllib modules are somewhat dated. IMO, The rant is not worthy of being on the front page of Hacker News.