On Mon, Dec 14, 2009 at 1:43 PM, Steven Bethard
<steven.beth...@gmail.com> wrote:
> On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking <i...@colorstudy.com> wrote:
>> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
>> <steven.beth...@gmail.com> wrote:
>>> So there wasn't really any more feedback on the last post of the
>>> argparse PEP other than a typo fix and another +1.
>>
>> I just converted a script over to argparse. It seems nice enough, I
>> was doing a two-level command, and it was quite handy for that.
>>
>> One concern I had is that the naming seems at times trivially
>> different than optparse, just because "opt" or "option" is replaced by
>> "arg" or "argument". So .add_option becomes .add_argument, and
>> OptionParser becomes ArgumentParser. This seems unnecessary to me,
>> and it make converting the application harder than it had to be. It
>> wasn't hard, but it could have been really easy. There are a couple
>> other details like this that I think are worth resolving if argparse
>> really is supposed to replace optparse.
>
> Thanks for the feedback. Could you comment further on exactly what
> would be sufficient? It would be easy, for example, to add a subclass
> of ArgumentParser called OptionParser that has an add_option method.
> Do you also need the following things to work?
>
> * options, args = parser.parse_args() # options and args aren't
> separate in argparse
> * type='int', etc. # string type names aren't used in argparse
> * action='store_false' default value is None # it's True in argparse
>
> These latter kind of changes seem sketchier to me - they would make
> the initial conversion easier, but would make using argparse normally
> harder.
>
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 ?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Free jacknife 1.3.4 v2 Download - mac software -
http://feedproxy.google.com/~r/TracGViz-full/~3/q0HBIH_50wQ/
_______________________________________________
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
