Here's my situation:  I originally used optparse, although some of the guys I worked with at the time were starting to use argparse.  At first I thought, I'm sticking with optparse, it's more standard than argparse and probably better supported.  But at some point optparse became documented as deprecated, with argparse being hailed as its replacement.

At that point my preference switched, again mostly because I wanted the most reliable, best supported option parsing package.  And yes, I have come to appreciate some of the features of argparse, but to me that takes a back seat to correct functionality.

The documentation for argparse promotes the idea that it completely subsumes optparse, and that applications that use optparse can easily be converted to use argparse.  And for the most part that's true, except that optparse identifies options correctly and argparse does not.  That really, really needs to be documented.

What I want is a supported, standard option parsing library that knows how to extract option values correctly.  I used to have that with optparse, but now I feel like the rug's been pulled out from under me.  optparse is supposedly deprecated, and argparse doesn't work.  So I either use a package that could be removed from Python distributions at any time, or I use a package that has dangerous bugs.  I don't find either alternative very attractive.

As I said, un-deprecating optparse would be sufficient, especially if people started adding some of the argparse functionality to it.  Creating a new package would work too.  But from what I've seen, it sounds like argparse is beyond hope of repair and will never work properly.  I.e., it's a dead-end development path.  So why isn't *argparse* deprecated?

I've always maintained that core functionality is of primary importance.  Shiny bells and whistles, no matter how useful, are of secondary importance.  In my opinion, the wrong package was deprecated.