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

[Vinay Sajip]

Changes by Vinay Sajip :


--
assignee: vinay.sajip -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vinay Sajip]

Changes by Vinay Sajip :


--
priority: release blocker -> normal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vinay Sajip]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vinay Sajip]

Vinay Sajip added the comment:

*Mea culpa. Autocorrect :-(

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[paul j3]

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: 

 'choices': ', '.join(ac)}

This last error could be corrected with:

'choices': ', '.join(map(repr, ac))

=

The initial message for this issue stated:

So that this feature is not foisted on every programmer that uses  
argparse it could be made an option to the ArgumentParser class with 
the (possible) additional refinement of specifying a minimum number 
of characters for the abbreviations.

That was ignored in the subsequent discussion and patches.

Other Choices issues

http://bugs.python.org/issue16468 - argparse only supports iterable choices
http://bugs.python.org/issue16418 - long choices
http://bugs.python.org/issue16977 - choices='abc' case

I recommend closing this issue, and depend on aliases for subparsers 
abbreviations.  The interaction with 'choices' is just too complicated to 
handle as proposed here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ned Deily]

Changes by Ned Deily :


--
priority: normal -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[paul j3]

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 will work 
is the longest, 'abc'.  The other will be rejected as ambiguous.

In contrast with optionals flags, an exact match has priority over (possibly 
ambiguous) abbreviations.  See parser._parse_optional

I also noticed when testing this that for regular 'choices', the abbreviated 
string is put in the Namespace.  

 add_argument('--foo', choices = ['one','two'])

can produce `Namespace(foo='on')`.  I suspect most developers would want 
`Namespace(foo='one')`, regardless of whether it was an exact match or partial. 
 You don't list choices if you are ok with partial matches.

This isn't a problem with `subparsers`, since an abbreviation match still 
invokes the right subparser, and even puts the right name in 'subparsers' dest. 
 But for regular choices the behavior is highly debatable.

This needs to be reverted.  It may be fixable, but it needs more testing and 
discussion.  For now it's an enhancement that is causing backward compatibility 
problems.

ps

I missed this issue when I made an effort to find all argparse issues several 
years ago.  I contributed to https://bugs.python.org/issue14365, the other 
abbreviations issue mentioned in the recent github thread.

--
keywords: +needs review -patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[paul j3]

Changes by paul j3 :


--
nosy: +paul.j3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Zachary Ware]

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,lost,long,longer} ...\nPROG: error: ambiguous choice: 'long' 
could match long, longer\n")

--
assignee:  -> vinay.sajip
nosy: +zach.ware
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file44157/abbr_bug_test.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

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: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Lawrence]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Ziemski]

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 of the reviewers (and Vinay's suggestion) as far as 
possible.

--
versions: +Python 3.4 -Python 3.3
Added file: http://bugs.python.org/file29271/abbrev_subcmds_incl_tests_3.4.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vinay Sajip]

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 abbreviation to the full command name.

--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
nosy: +tshepang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steven Bethard]

Steven Bethard  added the comment:

Modulo the comments already on the patch by others, this approach looks fine to 
me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

Éric Araujo  added the comment:

Reviewed.  Steven: the patch is complete, pending a few doc editions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Ziemski]

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_tests_3.3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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 work and conflicting 
abbreviations report an error.

--
stage:  -> test needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Ziemski]

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: http://bugs.python.org/file22973/abbrev_subcmds_3.3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Ziemski]

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

I have 3.3 compiled and running now. :-)

> feel free to ask for anything that’s not in the devguide or not clear.

Thanks for the offer!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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.  3.2 
is a stable release now; 3.2.2c1 is the candidate release of the next bugfix 
version of 3.2, which is one of the stable versions (with 2.7).

> So I'll have to find out how to install Python 3.3 in parallel to my 2.7.1
> Starting with "hg clone http://hg.python.org/cpython"; now.
Yep, there’s no need to install.  Cloning http://hg.python.org/cpython#default 
will get you 3.3.  If you already have a clone for 3.2, you can also pull the 
default branch in your existing clone; feel free to ask for anything that’s not 
in the devguide or not clear.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Ziemski]

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://hg.python.org/cpython"; now.

Until later (after reading http://docs.python.org/devguide/ by myself of course 
;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Ziemski]

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 stop bugging here with aliases.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Ziemski]

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 did it right.)

BTW: Éric mentioned aliases for argparse. 
For that I have done a patch too. 
I'll try to find the appropriate issue number here to post it.

--
keywords: +patch
Added file: http://bugs.python.org/file22957/abbrev_subcmds.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ned Deily]

Ned Deily  added the comment:

http://docs.python.org/devguide/patch.html

--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Ziemski]

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.

--
nosy: +chriz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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, eric.araujo
versions: +Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Peter Williams]

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 subcommands is allowed with the proviso that the abbreviation 
must be long enough to remove any ambiguity.

So that this feature is not foisted on every programmer that uses argparse it 
could be made an option to the ArgumentParser class with the (possible) 
additional refinement of specifying a minimum number of characters for the 
abbreviations.

--
components: Library (Lib)
messages: 141805
nosy: pwil3058
priority: normal
severity: normal
status: open
title: argparse: allow abbreviation of sub commands by users
type: feature request

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com