[issue12713] argparse: allow abbreviation of sub commands by users

Changes by Vinay Sajip : -- assignee: vinay.sajip -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue12713] argparse: allow abbreviation of sub commands by users

Changes by Vinay Sajip : -- priority: release blocker -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12713] argparse: allow abbreviation of sub commands by users

Roundup Robot added the comment: New changeset 3310ea7dbe30 by Vinay Sajip in branch 'default': Issue #12713: reverted fix pending further discussion. https://hg.python.org/cpython/rev/3310ea7dbe30 -- ___ Python tracker

[issue12713] argparse: allow abbreviation of sub commands by users

Vinay Sajip added the comment: Mean culpa - I have jumped the gun on this. Sorry to all for the inconvenience. I have just got back after being away for a few days, and will revert the change shortly, if no one beats me to it. -- ___ Python tracker

[issue12713] argparse: allow abbreviation of sub commands by users

Vinay Sajip added the comment: *Mea culpa. Autocorrect :-( -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue12713] argparse: allow abbreviation of sub commands by users

paul j3 added the comment: Another failure case: parser.add_argument('--int', type=int, choices=[10,15,25]) '--int 15` puts 'int=15' in the Namespace. '--int 2' puts 'int=2' in the Namespace, because it matches the 'str(25)'. '--int 1' raises an error in the ambiguity error formatting code:

[issue12713] argparse: allow abbreviation of sub commands by users

Changes by Ned Deily : -- priority: normal -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue12713] argparse: allow abbreviation of sub commands by users

paul j3 added the comment: I haven't read the discussion in full, but it looks like this patch was added without any recent discussion or testing. Previously if we had `choices=['a','abc']`, any exact match would be accepted, and partial matches rejected. With this change the only choice that

[issue12713] argparse: allow abbreviation of sub commands by users

Changes by paul j3 : -- nosy: +paul.j3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/

[issue12713] argparse: allow abbreviation of sub commands by users

Zachary Ware added the comment: There's a bug in this patch, first reported at https://github.com/python/benchmarks/issues/1 Attached patch causes test_parse_args_abbreviation to show the failure: test.test_argparse.ArgumentParserError: ('SystemExit', '', "usage: PROG [-h] [--foo] bar {1,2,3,

[issue12713] argparse: allow abbreviation of sub commands by users

Roundup Robot added the comment: New changeset 97b28115bd08 by Vinay Sajip in branch 'default': Closes #12713: Allowed abbreviation of subcommands in argparse. https://hg.python.org/cpython/rev/97b28115bd08 -- nosy: +python-dev resolution: -> fixed stage: test needed -> resolved status:

[issue12713] argparse: allow abbreviation of sub commands by users

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue12713] argparse: allow abbreviation of sub commands by users

Mark Lawrence added the comment: The latest patch seems okay to me. I've successfully applied it and ran the test suite and everything passed. Could someone please take a look with a view to getting this committed, thanks. -- nosy: +BreamoreBoy __

[issue12713] argparse: allow abbreviation of sub commands by users

Christian Ziemski added the comment: Ouch, I really missed this one for a long time. :-( (I didn't understand the workflow correctly and overlooked the reviews.) I apologize to everyone who has been involved! Finally I'm back here and re-did my patch for 3.4 this time. I followed the comments o

[issue12713] argparse: allow abbreviation of sub commands by users

Vinay Sajip added the comment: You could consider just a small refinement: in the first loop in _SubParsersAction.__call__ where you look for the abbreviation, you can just set parser_name = p and break. Then the logic just below that can stay as it is: all you've done is morphed the abbrevia

[issue12713] argparse: allow abbreviation of sub commands by users

Changes by Tshepang Lekhonkhobe : -- nosy: +tshepang ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue12713] argparse: allow abbreviation of sub commands by users

Steven Bethard added the comment: Modulo the comments already on the patch by others, this approach looks fine to me. -- ___ Python tracker ___

[issue12713] argparse: allow abbreviation of sub commands by users

Éric Araujo added the comment: Reviewed. Steven: the patch is complete, pending a few doc editions. -- ___ Python tracker ___ ___ Py

[issue12713] argparse: allow abbreviation of sub commands by users

Christian Ziemski added the comment: After some interesting hours of work (learning about tests) I created a new patch, including my original code changes as in the former patch and the new additional tests as well. -- Added file: http://bugs.python.org/file23001/abbrev_subcmds_plus_t

[issue12713] argparse: allow abbreviation of sub commands by users

Éric Araujo added the comment: test_argparse has a proper test infrastructure so that people don’t have to write the same boilerplate and assertion code over and over again. If you want, you can probably learn by copy-pasting things. What you want to test is basically that shortened forms wo

[issue12713] argparse: allow abbreviation of sub commands by users

Christian Ziemski added the comment: Attached a patch against Python 3.3 All the existing tests are still running successfully. But I wasn't able to add additional tests for the new functionality. Writing proper tests is a bit over my head for now - still learning. -- Added file: htt

[issue12713] argparse: allow abbreviation of sub commands by users

Éric Araujo added the comment: > http://python.org/download/releases/ Ah, I understand: the release candidate for 3.2.2 is a testing release, but not a development one :) -- ___ Python tracker ___

[issue12713] argparse: allow abbreviation of sub commands by users

Christian Ziemski added the comment: >> Even "the current development/testing version: Python 3.2.2 rc 1 >> (August 14, 2011)" isn't new enough here? > > No. (Where does the quote come from?) http://python.org/download/releases/ > Cloning http://hg.python.org/cpython#default will get you 3.3

[issue12713] argparse: allow abbreviation of sub commands by users

Éric Araujo added the comment: > Even "the current development/testing version: Python 3.2.2 rc 1 > (August 14, 2011)" isn't new enough here? No. (Where does the quote come from?) The current development version is 3.3; its version number is currently 3.3.0a0, to mean it was not released yet.

[issue12713] argparse: allow abbreviation of sub commands by users

Christian Ziemski added the comment: Just for my understanding: Even "the current development/testing version: Python 3.2.2 rc 1 (August 14, 2011)" isn't new enough here? So I'll have to find out how to install Python 3.3 in parallel to my 2.7.1 (on Fedora 15). Starting with "hg clone http:/

[issue12713] argparse: allow abbreviation of sub commands by users

Éric Araujo added the comment: Yes, I checked and aliases are already supported. You seem to have overlooked the Versions field on the top of this page: new features don’t go in stable releases, so your patch would have to apply to default, a.k.a. 3.3. -- ___

[issue12713] argparse: allow abbreviation of sub commands by users

Christian Ziemski added the comment: Since there seems to be no means to edit (my last) message a little followup regarding aliases: I found http://bugs.python.org/issue9234 "argparse: aliases for positional arguments (subparsers)" That one is for version 3.2 and already closed. So I'll sto

[issue12713] argparse: allow abbreviation of sub commands by users

Christian Ziemski added the comment: I attached a patch against argparse.py from Python 2.7.1. Subcommmands can now be abbreviated as long as they are unambiguous. Otherwise an error message 'ambigous choice' will be thrown (like the 'invalid choice' one). (It's my first patch, so hopefully I

[issue12713] argparse: allow abbreviation of sub commands by users

Ned Deily added the comment: http://docs.python.org/devguide/patch.html -- nosy: +ned.deily ___ Python tracker ___ ___ Python-bugs-li

[issue12713] argparse: allow abbreviation of sub commands by users

Christian Ziemski added the comment: I just made such a change to Python 2.7's argparse. If there is interest I'll post a patch here. Unfortunately I can't find the description how to produce a proper patch. The link I found (http://www.python.org/dev/patches/) gives an error 404. -- n

[issue12713] argparse: allow abbreviation of sub commands by users

Éric Araujo added the comment: Interesting idea. I know that with Mercurial for example, I use abbreviations and aliases all the time. Note that argparse already has aliases (or there is an open feature request about it). Steven: What do you think of this request? -- nosy: +bethard

[issue12713] argparse: allow abbreviation of sub commands by users

New submission from Peter Williams : Quite often the names of subcommands are quite long so that their meaning is clear. However, the downside to this is the increased typing the user of the command must make. A compromise between clarity and brevity can be realized if abbreviation of subcom