[3.11] gh-60346: Improve handling single-dash options in ArgumentParser.parse_known_args() (GH-114180)

[miss-islington]

(cherry picked from commit e47ecbd)

Co-authored-by: Serhiy Storchaka storchaka@gmail.com

• Issue: ArgumentParser inconsistent with parse_known_args #60346

[Erotemic]

Noting that adding a sep to the option_tuple broke my ArgumentParser extension which allows for flags to be insensitive to being specified as --foo-bar=123 or --foo_bar=123. Ultimately, it's my bad for overloading a non-public API, but it would've been nice if option tuple stayed consistent. Given that it already changed, it may be worth changing the option-tuple from a tuple to a namedtuple so the arguments can be unpacked explicitly rather than relying on the ordering of the tuple. I'm scratching my head wondering how I'm going to patch scriptconfig to handle this case.

What is the patch version of 3.11 that this was introduced in? 3.11.9?

[serhiy-storchaka]

Yes, in 3.11.9. You perhaps can just check the length of the tuple.

I think a named tuple is an overhead for a deeply internal API. It is just a way to return multiple values from a function.

Perhaps we could consider an idea of adding more general public API to solve your problem. For example, the ability to add hidden aliases or to transform options before comparison, so --foo-bar and /FOOBAR could be different spellings of the same option. Or simply ignore the difference between '-' and '_' in option names by default, since '-' is already translated to '_' in inferred destination. But these are different issues.

[bebound]

This change also broke argcomplete.
Related issue: kislyuk/argcomplete#481
Fixed in 3.3.0: kislyuk/argcomplete@54a4846