Pronouncement on PEP 389: argparse?
So there wasn't really any more feedback on the last post of the argparse PEP other than a typo fix and another +1. http://www.python.org/dev/peps/pep-0389/ Can I get a pronouncement? Here's a summary of the responses. (Please correct me if I misinterpreted anyone.) * Floris Bruynooghe +1 * Brett Cannon +1 * Nick Coghlan +1 * Michael Foord +1 * Yuval Greenfield +1 * Doug Hellmann +1 * Kevin Jacobs +1 * Paul Moore +1 * Jesse Noller +1 * Fernando Perez +1 * Jon Ribbens +1 * Vinay Sajip +1 * Barry Warsaw +1 * Antoine Pitrou -0 * Martin v. Löwis -0 * M.-A. Lemburg -1 Note that I've interpreted those who were opposed to the deprecation of getopt as -0 since the PEP no longer proposes that, only the deprecation of optparse. (People who opposed optparse's deprecation are still -1.) If there's any other information that would be helpful for a pronouncement, please let me know. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard <steven.bethard@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. I'd change this language: "The optparse module is deprecated, and has been replaced by the argparse module." To: "The optparse module is deprecated and will not be developed further; development will continue with the argparse module" There's a lot of scripts using optparse, and if they are successfully using it there's no reason to stop using it. The proposed language seems to imply it is wrong to keep using optparse, which I don't think is the case. And people can pick up on this kind of language and get all excitable about it. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking <ianb@colorstudy.com> wrote:
On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard <steven.bethard@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'd change this language: "The optparse module is deprecated, and has been replaced by the argparse module." To: "The optparse module is deprecated and will not be developed further; development will continue with the argparse module"
Done. Thanks! Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Mon, Dec 14, 2009 at 12:43 PM, Steven Bethard <steven.bethard@gmail.com> wrote:
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking <ianb@colorstudy.com> wrote:
On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard <steven.bethard@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?
Well, to argue against myself: having another class like OptionParser also feels like backward compatibility cruft. argparse is close enough to optparse (which is good) that I just wish it was a bit closer.
* options, args = parser.parse_args() # options and args aren't separate in argparse
This is a substantive enough difference that I don't really mind it, though if OptionParser really was a different class then maybe parse_args should act the same as optparse.OptionParser. What happens if you have positional arguments, but haven't declared any such arguments with .add_argument? Does it just result in an error? I suppose it must.
* type='int', etc. # string type names aren't used in argparse
This seems simple to support and unambiguous, so yeah.
* action='store_false' default value is None # it's True in argparse
I don't personally care about this; I agree the None default in optparse is sometimes peculiar (also for action='count' and action='append', where 0 and [] are the sensible defaults). Also I'd like %prog and %default supported, which should be fairly simple; heck, you could just do something like usage.replace('%prog', '%(prog)s') before substitution. Since %prog isn't otherwise valid (unless it was %%prog, which seems unlikely?) this seems easy. Ideally I really wish ArgumentParser was just named OptionParser, and that .add_argument was .add_option, and that argparse's current parse_args was named something different, so both the optparse parse_args (which returns (options, args)) and argparse's different parse_args return value could coexist. Also generally if the common small bits of optparse (like type='int' and %prog) just worked, even if they weren't really extensible in the same manner as optparse. Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question for argparse, but just generally I think that doing things the same way as optparse should be preferred when at all reasonable. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
On 14/12/2009 19:04, Ian Bicking wrote:
[snip...] Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question for argparse, but just generally I think that doing things the same way as optparse should be preferred when at all reasonable.
I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example). All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
On Mon, Dec 14, 2009 at 1:43 PM, Steven Bethard <steven.bethard@gmail.com> wrote:
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking <ianb@colorstudy.com> wrote:
On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard <steven.bethard@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/
On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
On 14/12/2009 19:04, Ian Bicking wrote:
[snip...] Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question for argparse, but just generally I think that doing things the same way as optparse should be preferred when at all reasonable.
I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example).
Many Unix commands accept these switches too . AFAICR there was an standard (well ...) set of command line options for Unix systems (can't find a link :-/ ) .. [1] Command-Line Options (http://www.faqs.org/docs/artu/ch10s05.html) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Automated init. - http://bitbucket.org/osimons/trac-rpc-mq/changeset/e122336d1eb2/
Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example).
+1 for letting -v mean "--verbose". This is a really common wish.
On 12/14/2009 1:43 PM, Steven Bethard wrote:
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking<ianb@colorstudy.com> wrote:
On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard <steven.bethard@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
On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang <olemis@gmail.com> wrote:
On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord
On 14/12/2009 19:04, Ian Bicking wrote:
Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question
I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example).
Many Unix commands accept these switches too . AFAICR there was an standard (well ...) set of command line options for Unix systems (can't find a link :-/ )
Just to be clear, argparse doesn't force you to use -v/--version. That's just the default if you specify the version= argument to the ArgumentParser constructor. You can configure version flags much more flexibly using add_argument(..., action='version'). But yes, it's a poll right now on the argparse website (http://code.google.com/p/argparse/) and if you feel strongly about it, please add your vote there (rather than here). Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis@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". Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Mon, Dec 14, 2009 at 3:00 PM, Steven Bethard <steven.bethard@gmail.com> wrote:
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis@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/
Antoine Pitrou wrote:
Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example).
+1 for letting -v mean "--verbose". This is a really common wish.
Agreed, all my scripts do that. -V is the short form I expect for --version. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Steven Bethard <steven.bethard <at> gmail.com> writes:
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.
Although I am of the people who think working modules shouldn't be deprecated, I also don't think adding compatibility aliases is a good idea. They only make the APIs more bloated and maintenance more tedious. Let's keep the new APIs clean of any unnecessary baggage. Regards Antoine.
Steven Bethard wrote:
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis@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@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Steven Bethard wrote:
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis@gmail.com> wrote:
I thought that one of the following approaches would be considered :
1 - let optparse remain in stdlib (as is or not ...) 2 - 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.
[...]
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,
So, I don't get it . What's the difference between this and the first option I mentioned above ? I am probably missing the obvious but if optparse will be «never deprecated in 2.x» then what's gonna happen ? The only options I see are mentioned above (and I thought it was the first one ;o) : - If (1) is the right one then -0 for considering backwards compatibility - If (2) is the right one then IMO, +1 for adding «further backwards compatibility cruft» in a separate module and remove it in Python 3.5 -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Looking for a technique to create flexible, graphical dashboards ... - http://feedproxy.google.com/~r/TracGViz-full/~3/r7Zcyrg1n3U/019aa74e7095d047
On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang <olemis@gmail.com> wrote:
On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis@gmail.com> wrote:
I thought that one of the following approaches would be considered : 1 - let optparse remain in stdlib (as is or not ...) 2 - re-implement optparse (i.e. a module having the same name ;o) using argparse
People also need to remember the very conservative deprecation path for optparse proposed in the PEP - never deprecated in 2.x,
So, I don't get it . What's the difference between this and the first option I mentioned above ? I am probably missing the obvious but if optparse will be «never deprecated in 2.x» then what's gonna happen ? The only options I see are mentioned above (and I thought it was the first one ;o) :
- If (1) is the right one then -0 for considering backwards compatibility - If (2) is the right one then IMO, +1 for adding «further backwards compatibility cruft» in a separate module and remove it in Python 3.5
If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the "Deprecation of optparse" section of the PEP: http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
Ian Bicking <ianb@colorstudy.com> writes:
Ideally I really wish ArgumentParser was just named OptionParser, and that .add_argument was .add_option, and that argparse's current parse_args was named something different, so both the optparse parse_args (which returns (options, args)) and argparse's different parse_args return value could coexist.
-1 for pretending that “option” and “argument” mean the same thing. They really don't (the former is a strict subset of the latter), and it would be confusing legacy cruft if argparse had names that imply it. The names chosen in the argparse library are good.
if OptionParser really was a different class then maybe parse_args should act the same as optparse.OptionParser.
+1 for “optparse API and external behaviour re-implemented as an ‘optparse’ module using argparse as the underlying implementation”, to allow exactly the sort of ease of transition you're describing. Of course, that +1 is only support for “someone else does the work”. I don't need optparse to remain if I have argparse in the standard library. +0 for deprecating optparse. -- \ “… it's best to confuse only one issue at a time.” —Brian W. | `\ Kernighan and Dennis M. Ritchie, _The C programming language_, | _o__) 1988 | Ben Finney
On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote:
Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example).
+1 for letting -v mean "--verbose". This is a really common wish.
+1, -v == --verbose S
On Mon, Dec 14, 2009 at 12:35, Antoine Pitrou <solipsis@pitrou.net> wrote:
Steven Bethard <steven.bethard <at> gmail.com> writes:
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.
Although I am of the people who think working modules shouldn't be deprecated, I also don't think adding compatibility aliases is a good idea. They only make the APIs more bloated and maintenance more tedious. Let's keep the new APIs clean of any unnecessary baggage.
Ditto from me. If people want a compatible module it can be made available on PyPI for those who want it. -Brett
On Dec 14, 2009, at 2:55 PM, Steven Bethard wrote:
On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang <olemis@gmail.com> wrote:
On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord
On 14/12/2009 19:04, Ian Bicking wrote:
Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question
I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example).
Many Unix commands accept these switches too . AFAICR there was an standard (well ...) set of command line options for Unix systems (can't find a link :-/ )
How about this one: http://www.shelldorado.com/goodcoding/cmdargs.html#flagnames S
On Dec 14, 2009, at 2:55 PM, Steven Bethard wrote:
But yes, it's a poll right now on the argparse website (http://code.google.com/p/argparse/) and if you feel strongly about it, please add your vote there (rather than here).
I don't even understand what the poll question is asking. S
On Dec 14, 2009, at 3:35 PM, Antoine Pitrou wrote:
Steven Bethard <steven.bethard <at> gmail.com> writes:
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.
Although I am of the people who think working modules shouldn't be deprecated, I also don't think adding compatibility aliases is a good idea. They only make the APIs more bloated and maintenance more tedious. Let's keep the new APIs clean of any unnecessary baggage.
Agreed. If you want to make an "adapter" to do things like convert 'int' to int, then call the new API then fine, but don't start crufting up a new API to make it 'easier' to convert. All crufting it up does is make it _less_ clear how to use the new API by bring along things that don't belong in it. S
On Mon, Dec 14, 2009 at 6:34 PM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
Although I am of the people who think working modules shouldn't be deprecated, I also don't think adding compatibility aliases is a good idea. They only make the APIs more bloated and maintenance more tedious. Let's keep the new APIs clean of any unnecessary baggage.
Agreed. If you want to make an "adapter" to do things like convert 'int' to int, then call the new API then fine, but don't start crufting up a new API to make it 'easier' to convert.
All crufting it up does is make it _less_ clear how to use the new API by bring along things that don't belong in it.
The "new" API is almost exactly like the old optparse API. It's not like it's some shining jewel of perfection that would be tainted by somehow being similar to optparse when it's almost exactly like optparse already. If it wasn't like optparse, then fine, whatever; but it *is* like optparse, so these differences feel unnecessary. Converting 'int' to int internally in argparse is hardly difficult or unclear. If argparse doesn't do this, then I think at least it should give good error messages for all cases where these optparse-isms remain. For instance, now if you include %prog in your usage you get: ValueError: unsupported format character 'p' (0x70) at index 1 -- that's simply a bad error message. Giving a proper error message takes about as much code as making %prog work. I don't feel strongly that one is better than the other, but at least one of those should be done. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
On Mon, Dec 14, 2009 at 4:16 PM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote:
Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example).
+1 for letting -v mean "--verbose". This is a really common wish.
+1, -v == --verbose
Because people are continuing this discussion, I'll say again that argparse already supports this:
parser = argparse.ArgumentParser() parser.add_argument('-v', '--verbose', action='store_true') parser.parse_args(['-v']) Namespace(verbose=True)
If you want to also have a -V/--version argument, you can do that too:
parser.add_argument('-V', '--version', action='version', version='3.5') parser.parse_args(['-V']) 3.5
And now back to our regularly scheduled discussion of actual PEP issues. ;-) Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
Steven Bethard <steven.bethard <at> gmail.com> writes:
Because people are continuing this discussion, I'll say again that argparse already supports this:
Well I think the point is that if there is a default, the default should be sensible and not run against expectations. It would probably be fine not to have a default at all, too. Regards Antoine.
Ian Bicking wrote:
On Mon, Dec 14, 2009 at 6:34 PM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
Although I am of the people who think working modules shouldn't be deprecated, I also don't think adding compatibility aliases is a good idea. They only make the APIs more bloated and maintenance more tedious. Let's keep the new APIs clean of any unnecessary baggage.
Agreed. If you want to make an "adapter" to do things like convert 'int' to int, then call the new API then fine, but don't start crufting up a new API to make it 'easier' to convert.
All crufting it up does is make it _less_ clear how to use the new API by bring along things that don't belong in it.
The "new" API is almost exactly like the old optparse API. It's not like it's some shining jewel of perfection that would be tainted by somehow being similar to optparse when it's almost exactly like optparse already.
If it wasn't like optparse, then fine, whatever; but it *is* like optparse, so these differences feel unnecessary. Converting 'int' to int internally in argparse is hardly difficult or unclear.
If argparse doesn't do this, then I think at least it should give good error messages for all cases where these optparse-isms remain. For instance, now if you include %prog in your usage you get: ValueError: unsupported format character 'p' (0x70) at index 1 -- that's simply a bad error message. Giving a proper error message takes about as much code as making %prog work. I don't feel strongly that one is better than the other, but at least one of those should be done.
I agree (and I've used both for quite a long time). argparse has an api that is almost compatible with optparse in many common cases, but just renamed some things.
On Tue, Dec 15, 2009 at 4:33 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Ian Bicking wrote:
If argparse doesn't do this, then I think at least it should give good error messages for all cases where these optparse-isms remain. For instance, now if you include %prog in your usage you get: ValueError: unsupported format character 'p' (0x70) at index 1 -- that's simply a bad error message. Giving a proper error message takes about as much code as making %prog work. I don't feel strongly that one is better than the other, but at least one of those should be done.
I agree (and I've used both for quite a long time). argparse has an api that is almost compatible with optparse in many common cases, but just renamed some things.
I can definitely improve some of the error messages for people coming from optparse. I've created an issue for this, with the ``type='int'`` and "%prog" problems in there: http://code.google.com/p/argparse/issues/detail?id=51 If you have other things that you know you'd like better exceptions for, please add to that issue and I'll take care of it. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard <steven.bethard@gmail.com> wrote:
If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the "Deprecation of optparse" section of the PEP:
http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
I do not think that optparse should be deprecated at. It is good at what it does and its limitations make its starting point less confusing for people with different backgrounds that Python. Compare: http://docs.python.org/library/optparse.html http://argparse.googlecode.com/svn/tags/r101/doc/index.html argparse should be recommended as advanced and more featured variant of optparse - that goes without saying, but forcing people to switch and annoying them with deprecation messages brings only headache. Just like optparse is better getopt, the latter could also be useful for people coming from other languages and porting their libraries to Python. I would better concentrate on real code examples how argparse solves problems and would really want to see http://www.python.org/dev/peps/pep-0389/#out-of-scope-various-feature-reques... implemented until argparse enters phase where backward incompatible changes in API are impossible. I would prefer to see PEP 389 as a document describing proposed solutions to argument parsing problems rather than petition to replace one library with another. So, it should display common argument parsing scenarios (use cases) with examples that are also useful recipes for documentation. I guess more than 90% people here doesn't have time to read argparse methods descriptions to see what they could be useful for. -- anatoly t.
On Sun, Dec 27, 2009 at 9:51 AM, anatoly techtonik <techtonik@gmail.com> wrote:
On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard <steven.bethard@gmail.com> wrote:
If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the "Deprecation of optparse" section of the PEP:
http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
I do not think that optparse should be deprecated at. It is good at what it does and its limitations make its starting point less confusing for people with different backgrounds that Python.
Compare: http://docs.python.org/library/optparse.html http://argparse.googlecode.com/svn/tags/r101/doc/index.html
This sounds like a request for a documentation change. Because you can write almost identical code with argparse to that in the optparse intro. If you just replace "optparse" with "argparse", "OptionParser" with "ArgumentParser", and "(options, args)" with "args", the code will work exactly the same. (Actually, better because the usage message will be better.) If you have specific suggestions on how you'd like the documentation updated, please file a feature request in the argparse bug tracker: http://code.google.com/p/argparse/issues Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Sun, Dec 27, 2009 at 11:21 PM, anatoly techtonik <techtonik@gmail.com>wrote:
On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard <steven.bethard@gmail.com> wrote:
If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the "Deprecation of optparse" section of the PEP:
http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
I do not think that optparse should be deprecated at. It is good at what it does and its limitations make its starting point less confusing for people with different backgrounds that Python.
Ref http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse . Considering that optparse will be deprecated like 5 years from now. I think this point is moot. The deprecation strategy IMHO is perhaps way too conservative. Maybe it should be deprecated faster ;) -- --Anand
If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the "Deprecation of optparse" section of the PEP:
http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
I do not think that optparse should be deprecated at. It is good at what it does and its limitations make its starting point less confusing for people with different backgrounds that Python.
Compare: http://docs.python.org/library/optparse.html http://argparse.googlecode.com/svn/tags/r101/doc/index.html
argparse should be recommended as advanced and more featured variant of optparse - that goes without saying, but forcing people to switch and annoying them with deprecation messages brings only headache.
As has been noted already nobody is forcing people to switch. Optparse will be available as a separate package and everybody will be free to install it and will not have any deprecation messages anywhere.
Just like optparse is better getopt, the latter could also be useful for people coming from other languages and porting their libraries to Python.
I would better concentrate on real code examples how argparse solves problems and would really want to see http://www.python.org/dev/peps/pep-0389/#out-of-scope-various-feature-reques... implemented until argparse enters phase where backward incompatible changes in API are impossible.
I would prefer to see PEP 389 as a document describing proposed solutions to argument parsing problems rather than petition to replace one library with another. So, it should display common argument parsing scenarios (use cases) with examples that are also useful recipes for documentation. I guess more than 90% people here doesn't have time to read argparse methods descriptions to see what they could be useful for.
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown
participants (15)
-
Anand Balachandran Pillai -
anatoly techtonik -
Antoine Pitrou -
Ben Finney -
Brett Cannon -
Daniel Fetchinson -
Ian Bicking -
Michael Foord -
Neal Becker -
Nick Coghlan -
Olemis Lang -
Simon Brunning -
ssteinerX＠gmail.com -
Steven Bethard -
Terry Reedy