Make _MutuallyExclusiveGroup a public API in argparse

[gaborbernat]

argparse.ArgumentParser.add_mutually_exclusive_group() returns an argparse._MutuallyExclusiveGroup instance, but this type is private (underscore-prefixed). This makes it impossible to properly type-annotate code that stores the return value without importing a private symbol.

Motivation

When using type checkers (mypy, ty, pyright), code like:

group = parser.add_argument_group("selection")
add_to: ArgumentParser = group.add_mutually_exclusive_group(required=False)

is flagged as a type error because _MutuallyExclusiveGroup is not ArgumentParser, but there's no public type to use instead. The only workaround is importing the private _MutuallyExclusiveGroup.

This is similar to #101503 which requests making the return type of add_subparsers public.

Proposal

Make _MutuallyExclusiveGroup (and possibly _ArgumentGroup) public by removing the underscore prefix, or at minimum export a public type alias.

Linked PRs

• gh-144812: Add public argparse group typing protocols #150597

[serhiy-storchaka]

I think typing issues are not a good reason to make inner classes public.

Create a protocol, and use it. This is the right way in dynamically typed programming languages like Python. Or just use non-public classes if you are not afraid that your code can break with future Python versions.

[gaborbernat]

Create a protocol, and use it.

I'm alright with the protocol approach, however I think that should live in CPython. Python is exposing an interface here, so should be able to expose a machine readable variant of it too (which types essentially are, so type checkers know what contract user code should follow).

[picnixz]

Exposing an interface does not mean that its implementation should be exposed. We could document that only the name becomes public (like we did for Action) and that it should be treated as a protocol (kinda) but if we were to do something within the stdlib, creating protocols would be better (though, it would come at some cost oj our side).

[mpkocher]

I'm alright with the protocol approach, however I think that should live in CPython. Python is exposing an interface here, so should be able to expose a machine readable variant of it too (which types essentially are, so type checkers know what contract user code should follow).

I agree.

If the type hints/annotations were defined in argparse.py instead of a pyi file in typeshed, there wouldn't be an issue. One could define a new structural type, MutuallyExclusiveGroupT via Protocol in argparse.py and that would be the end of it.

However, having some of the types/interfaces/protocols defined in typeshed while others defined in cpython argparse.py is probably not a great direction to start going down. Having this bifurcation would be confusing and it's not a great interface for the average user.

I wish there was a clearer path forward to fundamentally address these types of issues.

[mpkocher]

Or just use non-public classes if you are not afraid that your code can break with future Python versions.

https://github.com/search?q=%22argparse._MutuallyExclusiveGroup%22+language%3APython&type=code