Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hmm, I was going to list additional standard libraries that I use on a regular basis to "prove" the author wrong, but I could only come up with two (in addition to your list): csv & re.

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.



I can come up with quite a few of them.

    os
    sys
    logging
    os.path
    re
    subprocess
    datetime
    json
    pickle
    itertools
    urllib2
    signal
    traceback
    socket
It has a lot to do with my job - devops for remote clients. I can't rely on the ability to use 3rd party python libraries, and my stuff has to work reliably with few problematic corner cases. The standard library fulfills both of those cases pretty well.

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.


If I may ask, what's wrong with datetime? I may not have encountered unusual cases, but for most uses the date + datetime + timedelta scheme seems to work pretty well.


I don't think anything is wrong with datetime - it's just a stdlib tool that I use on a regular basis. Sorry, wasn't listing just those I think have warts or those replaced by other tools, just libs that I use regularly.


My only gripe with datetime and time are the organization of it. I can never remember whether it's datetime.datetime.now or datetime.now or time.timedelta or datetime.timedelta, and so on.


Yeah, typing datetime.datetime for everything gets pretty old.

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.


I also like using argparse. Nice utility library to "power up" helpful scripts.


Argument parsing is an essential utility and part of the standard library in all major programming languages, though. Dating back to getopt becoming a standard in C (or earlier?)

Or do you find Python's argument parsing to be especially notable for some reason?


For a language whose motto is "There should be one - and preferably only one - obvious way to do it", Python has at least four ways to handle command line arguments out-of-the-box:

* sys.argv

* argparse

* optparse

* getopt

There are, of course, additional third party modules (like opster) that also handle arguments.


sys.argv is part of the interpreter. The other three are abstractions over it.

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.


Is getopt part of the C library? I think it only is POSIX, not C.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: