On 12/14/2009 1:43 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking<ianb at colorstudy.com> wrote: >> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard >> <steven.bethard at 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? [snip] I have not ever used optparse. So if I were to use argparse in the future, I would strongly prefer that it be free of back-compatibility cruft. Would it be possible to use the 2to3 machinery to write an opt_to_arg conversion tool? This could easily take care of the naming differences. Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4