On Mon, Dec 14, 2009 at 3:00 PM, Steven Bethard
<steven.beth...@gmail.com> wrote:
> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <ole...@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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
