[Python-Dev] Pronouncement on PEP 389: argparse? (original) (raw)

Olemis Lang olemis at gmail.com
Mon Dec 14 21:20:45 CET 2009

On Mon, Dec 14, 2009 at 3:00 PM, Steven Bethard <steven.bethard at gmail.com> 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.

Well, I was actually thinking about adding such aliases in that module and leave argparse just like it is today (and make the aliases as compatible with optparse as possible ;o). So probably we're talking about very similar things that will be placed in different places in stdlib .

For what it's worth, I'm still not sure it's a good idea,

... at least that way changes to have optparse-like interface will be in a separate module. Or otherwise implement optparse like shown below

{{{ #!python

from argparse.optparse import * }}}

and do the rest in argparse (it's the same anyway ;o)

-- Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/

Featured article: Initial version of protocol-provider patch. Patch does not currently apply cleanly - it hasn'... - http://bitbucket.org/osimons/trac-rpc-mq/changeset/b302540a1608/

More information about the Python-Dev mailing list