[Python-Dev] Pronouncement on PEP 389: argparse?

[Nick Coghlan]

Steven Bethard wrote:
> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis at gmail.com> wrote:
>> I thought that one of the following approaches would be considered :
>>
>>  - let optparse remain in stdlib (as is or not ...)
>>  - re-implement optparse (i.e. a module having the same name ;o) using
>>    argparse
>>
>> isn't it ?
> 
> Please read the PEP if you haven't, particularly the "Why isn't the
> functionality just being added to optparse?" section. I don't believe
> it is sensible to re-implement all of optparse. What Ian Bicking is
> proposing, I believe, is simpler -- adding a few aliases here and
> there so that you don't have to rename so many things when you're
> upgrading from optparse to argparse.
> 
> For what it's worth, I'm still not sure it's a good idea, for exactly
> the reason Ian points out - "having another class like OptionParser
> also feels like backward compatibility cruft".

People also need to remember the very conservative deprecation path for
optparse proposed in the PEP - never deprecated in 2.x, and only a
PendingDeprecationWarning in 3.x up until 3.4 (likely to happen some
time in 2013).

With that kind of slow deprecation path, adding further backwards
compatibility cruft to argparse itself seems redundant - the name
changes from option to argument were instituted for a reason (since the
scope of argparse really is wider than that of optparse).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------