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