Skip to content

bpo-33109: argparse subparsers are once again not required by default #6919

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 24, 2018

Conversation

ned-deily
Copy link
Member

@ned-deily ned-deily commented May 16, 2018

bpo-26510 in 3.7.0a2 changed the behavior of argparse to make
subparsers required by default, returning to the behavior of 2.7
and 3.2. The behavior was changed in 3.3 to be no longer required.
While it might make more sense to have the default to required,
compatibility with 3.3 through 3.6 is probably less disruptive
than trying to reintroduce compatibility with 2.7 at this point.
This change restores the 3.6 behavior.

https://bugs.python.org/issue33109

bpo-26510 in 3.7.0a2 changed the behavior of argparse to make
subparsers required by default, returning to the behavior of 2.7
and 3.2. The behavior was changed in 3.3 to be no longer required.
While it might make more sense to have the default to required,
compatibility with 3.3 through 3.6 is probably less disruptive
than trying to reintroduce compatibility with 2.7 at this point.
This change restores the 3.6 behavior.
@asottile
Copy link
Contributor

I still think we should consider the new behaviour more correct and the 3.3-3.6 behaviour a bug. This reintroduces the bug.

@ned-deily
Copy link
Member Author

@asottile Understood but see the discussion in https://bugs.python.org/issue33109 as to why we agree that compatibility with 3.6 is more important. Counterarguments welcome there!

@@ -1077,7 +1077,7 @@ def __init__(self,
prog,
parser_class,
dest=SUPPRESS,
required=True,
required=False,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we are here, please move required to the end of the list of parameters. It was inserted in the middle of non-keyword-only parameters.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was discussed here

It makes no difference because add_subparsers does not take positional arguments (all arguments are keyword-only). The ordering here was chosen to be consistent with the rest of the classes in the module

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry. You are right.

@ned-deily ned-deily merged commit 8ebf5ce into python:master May 24, 2018
@miss-islington
Copy link
Contributor

Thanks @ned-deily for the PR 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

@ned-deily ned-deily deleted the bpo-33109 branch May 24, 2018 01:55
@bedevere-bot
Copy link

GH-7089 is a backport of this pull request to the 3.7 branch.

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request May 24, 2018
…pythonGH-6919)

bpo-26510 in 3.7.0a2 changed the behavior of argparse to make
subparsers required by default, returning to the behavior of 2.7
and 3.2. The behavior was changed in 3.3 to be no longer required.
While it might make more sense to have the default to required,
compatibility with 3.3 through 3.6 is probably less disruptive
than trying to reintroduce compatibility with 2.7 at this point.
This change restores the 3.6 behavior.
(cherry picked from commit 8ebf5ce)

Co-authored-by: Ned Deily <nad@python.org>
ned-deily added a commit that referenced this pull request May 24, 2018
…GH-6919) (GH-7089)

bpo-26510 in 3.7.0a2 changed the behavior of argparse to make
subparsers required by default, returning to the behavior of 2.7
and 3.2. The behavior was changed in 3.3 to be no longer required.
While it might make more sense to have the default to required,
compatibility with 3.3 through 3.6 is probably less disruptive
than trying to reintroduce compatibility with 2.7 at this point.
This change restores the 3.6 behavior.
(cherry picked from commit 8ebf5ce)

Co-authored-by: Ned Deily <nad@python.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants