[stdlib-sig] Breaking out the stdlib

Laura Creighton lac at openend.se
Tue Sep 15 19:02:09 CEST 2009


In a message of Tue, 15 Sep 2009 14:38:20 -0000, Collin Winter writes:

<stuff that indicates that  my users shouldn't be changing versions
of Python without going through some sort of migration process>

This is what happens every time /usr/bin/env python changes.

<lots of stuff indicating that optparse really should be removed
 on the grounds that it is poorly written, still buggy, and 
 unmaintained>

Ok, so it's type B-2, the maintainer's nightmare.  It probably fits
in the category of 'things that never should be in the library in
the first place'.  It's an embarassment.  I notice that you aren't
talking about getopt, though.

And there may be things that are so badly written that we actually want
to throw them out of the standard library before people start using them.
A note 'this module only exists for backwards compatibility, we
recommend that you use XXX instead' will not be good enough for the
purpose, we really want to stamp out the use of this mistake as soon
and as well as possible.  This could happen.

But, as much as I dislike optparse, I don't think that this is the module
where that happened.  I will be happy when people stop using it, but
I don't think that using it is so hazardous that we should force all
the optparse users to rewrite all their code.

final quote:

>To speak more personally, and specifically to the issue of
>getopt/optparse vs argparse: at Google, I'm part of the Python
>readability team, which helps train the large numbers of Python
>developers that the company produces. Part of this job involves
>conducting detailed code reviews for new Python programmers,
>explaining both Google style and idiomatic Python code generally,
>suggesting library A over hand-written solution B. I am, frankly,
>embarrassed whenever I have to explain the difference between getopt
>and optparse, urllib and urllib2, popen2 vs os.popen* vs subprocess,
>string.* vs str.*, etc. I cannot imagine how embarrassed I will be
>when I have to explain why the standard library includes getopt,
>optparse and argparse.

You need to practice saying 'argparse is the preferred way to do
things; getopt and optparse are maintained for compatibility reasons'
until you can do this without embarassment.

It also sounds to me as if you would be far less embarassed explaining
to Google employees why they have to go off and rewrite all their old
code which uses getopt than explaining to them why we have getopt,
optparse, and argparse in the standard library.  I find this very odd.

Laura

>
>Collin Winter


More information about the stdlib-sig mailing list