love/hate python stdlib modules

Titus wants to know which standard library modules we use frequently, even though we don’t like how they work or find the documentation confusing.

re – I can never remember the difference between search() and match()

timeit – I haven’t actually used it that often, but find the API a little weird. Why do I pass the text of the code to time, instead of a callable like a function or method?

optparse – It’s not very object oriented. Why do I give a name for the action, instead of instantiating different types of option handlers for different behaviors?

logging – There are so many options. It has great potential, but I always have to look for an example to get a basic configuration setup.

bisect – Why isn’t this handled as a method of list? Something like insert_sorted()?

distutils – Don’t even get me started.

What are yours?
  • http://www.plope.com/ Chris McDonough

    “”" distutils – dont even get me started “”"

    hahaha… +1

  • http://www.plope.com/ Chris McDonough

    oh.. and ConfigParser. I always need to subclass it.

  • http://www.parand.com/say/ Parand

    +1 on timeit – pass text of the code around? That’s just odd.

  • http://www.algorithm.co.il/blogs/ lorg

    -1 on re. I really like the code there, and I don’t share your confusion.

    +1 on timeit and distutils These are modules that I want to use more, but every time I am discouraged by the interface.

    When I pass the barrier of simple ‘if argv[1] == “-t”‘ I go directly to optparse (there also reading the docs) instead of getopt.

    I disagree regarding logging and optparse though. I think the reason that I need the documentation every time is that I don’t use them as frequently as other modules.

  • http://www.blogger.com/profile/02378325626847644096 Josef Assad

    optparse bugs me too.

    I’m writing a CLI app which takes a pretty flexible set of parameters and it’d have been a lo easier if one could just iterate over the stored options dorectly. I know you can do it if youexpose the __dict__ but isn’t it more natural to just go:

    for i in options:
    # do something

  • http://www.blogger.com/profile/01892352754222143463 Doug Hellmann

    @chris – I have subclassed ConfigParser, but I don’t always. What sorts of subclasses do you create?

    @josef – Maybe you should look at getopt? I know optparse is the newer way, but it sounds like the getopt API might work better for what you’re doing.

  • http://www.plope.com/ Chris McDonough

    Doug: See UnhosedConfigParser in this module ;-)

  • http://www.blogger.com/profile/01892352754222143463 Doug Hellmann

    @Chris – Ah, yes, providing a default for get() is one of the things I’ve added, too. Maybe we should submit a patch to the standard library?