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.

Author meinersbur
Recipients berker.peksag, bethard, meinersbur, xiang.zhang
Date 2016-05-06.14:53:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1462546406.84.0.0214191693196.issue26967@psf.upfronthosting.co.za>
In-reply-to
Content
I think the allow_abbrev option should be orthogonal on how short options are parsed. I am using parse_known_args() to forward the unrecognized args to another program, therefore allow_abbrev=False is essential.

There is a special handling for short options in the consume_optional and _get_option_tuples to allow them being concatenated with one dash, as commonly done with short options (eg. "tar -czf file"). I interpret allow_abbrev as an option to avoid matching non-exiting options that should be forwarded to the other program; '-vv' is an existing option with the same meaning as '-v -v'.

This would also mean that parse_known_args(['-vz']) (where '-v' is a registered argument, but '-z' is not) matches '-v' and returns '-z' as unknown argument; but I don't know whether you want to go that far. It is difficult to interpret whether '-verify' should mean '-v -e -r -i -f -y' or '--verify' (but this is why there are double-dash options), especially when the first letter is not a registered short option.
History
Date User Action Args
2016-05-06 14:53:26meinersbursetrecipients: + meinersbur, bethard, berker.peksag, xiang.zhang
2016-05-06 14:53:26meinersbursetmessageid: <1462546406.84.0.0214191693196.issue26967@psf.upfronthosting.co.za>
2016-05-06 14:53:26meinersburlinkissue26967 messages
2016-05-06 14:53:26meinersburcreate