➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2013-11-27 14:16 by eli.bendersky, last changed 2022-04-11 14:57 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| issue19814.doc33.patch | eli.bendersky, 2013-11-27 14:33 | |||
| Messages (7) | |||
|---|---|---|---|
| msg204584 - (view) | Author: Eli Bendersky (eli.bendersky) *  |
Date: 2013-11-27 14:16 | |
Prefix matching behavior can lead to bugs when combined with parse_known_args. See this thread for more details: https://mail.python.org/pipermail/python-dev/2013-November/130601.html Issue #14910 deals with making it optional, but until 3.5 we'll have to do with a documentation warning. |
|||
| msg204589 - (view) | Author: Eli Bendersky (eli.bendersky) * |
Date: 2013-11-27 14:33 | |
Here's a patch for 3.3; if it looks ok i'll merge it to default and also to 2.7 |
|||
| msg204647 - (view) | Author: paul j3 (paul.j3) *  |
Date: 2013-11-28 08:38 | |
`parse_args` just calls `parse_known_args`, and then raises an error if `rest` is not empty. So it is `parse_known_args` that is doing the abbreviation matching.
Abbreviation matching is done relatively early, when `_parse_known_args` first loops through the strings, trying to decide which are arguments ('A') and which are options ('O'). This matching is done in `_parse_optional`. It's not something it does at the end on the 'leftovers'.
http://bugs.python.org/issue14910, a disable abbreviation option, might be a better solution. Your example is an argument in favor of implementing that feature.
Unless a reader has your example in mind, the proposed documentation warning might be more confusing than helpful.
|
|||
| msg204651 - (view) | Author: Eli Bendersky (eli.bendersky) * |
Date: 2013-11-28 13:44 | |
I don't see how these implementation details are relevant. The patch adds a link to the existing abbreviations section, which mentions parse_args - so it's clear that this behavior exists in both. Yes, #14910 (to which I pointed in the original message in this issue) is the long term solution, but it's only for Python 3.5; until then, as the mailing discussion has demonstrated, the documentation is unclear on this matter and needs clarification. |
|||
| msg204664 - (view) | Author: Eli Bendersky (eli.bendersky) * |
Date: 2013-11-28 14:43 | |
If I don't see any further objections I'll go ahead and commit this by the end of the week |
|||
| msg205010 - (view) | Author: Roundup Robot (python-dev) |
Date: 2013-12-02 13:50 | |
New changeset c457bd1935f9 by Eli Bendersky in branch '3.3': Issue #19814: Clarify argparse's docs w.r.t prefix matching http://hg.python.org/cpython/rev/c457bd1935f9 New changeset 46976bd44bfc by Eli Bendersky in branch 'default': Issue #19814: Clarify argparse's docs w.r.t prefix matching http://hg.python.org/cpython/rev/46976bd44bfc |
|||
| msg205011 - (view) | Author: Roundup Robot (python-dev) |
Date: 2013-12-02 13:53 | |
New changeset 181ced5bf0be by Eli Bendersky in branch '2.7': Issue #19814: Clarify argparse's docs w.r.t prefix matching http://hg.python.org/cpython/rev/181ced5bf0be |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:57:54 | admin | set | github: 64013 |
| 2013-12-02 13:53:52 | eli.bendersky | set | status: open -> closed resolution: fixed stage: resolved |
| 2013-12-02 13:53:36 | python-dev | set | messages: + msg205011 |
| 2013-12-02 13:50:50 | python-dev | set | nosy:
+ python-dev messages: + msg205010 |
| 2013-11-28 14:43:55 | eli.bendersky | set | messages: + msg204664 |
| 2013-11-28 13:44:29 | eli.bendersky | set | messages: + msg204651 |
| 2013-11-28 08:38:23 | paul.j3 | set | nosy:
+ paul.j3 messages: + msg204647 |
| 2013-11-27 14:33:25 | eli.bendersky | set | files:
+ issue19814.doc33.patch keywords: + patch messages: + msg204589 |
| 2013-11-27 14:16:01 | eli.bendersky | create | |