Skip to content
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

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

Merged
merged 1 commit into from May 24, 2018

Conversation

Projects
None yet
6 participants
@ned-deily
Copy link
Member

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-33109: argparse subparsers are once again not required by default
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

This comment has been minimized.

Copy link
Contributor

commented May 16, 2018

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

This comment has been minimized.

Copy link
Member Author

commented May 16, 2018

@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,

This comment has been minimized.

Copy link
@serhiy-storchaka

serhiy-storchaka May 22, 2018

Member

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.

This comment has been minimized.

Copy link
@asottile

asottile May 22, 2018

Contributor

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

This comment has been minimized.

Copy link
@serhiy-storchaka

serhiy-storchaka May 22, 2018

Member

Oh, sorry. You are right.

@ned-deily ned-deily merged commit 8ebf5ce into python:master May 24, 2018

4 checks passed

bedevere/issue-number Issue number 33109 found
Details
bedevere/news News entry found in Misc/NEWS.d
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@miss-islington

This comment has been minimized.

Copy link

commented May 24, 2018

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

@ned-deily ned-deily deleted the ned-deily:bpo-33109 branch May 24, 2018

@bedevere-bot

This comment has been minimized.

Copy link

commented May 24, 2018

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

miss-islington added a commit to miss-islington/cpython that referenced this pull request May 24, 2018

bpo-33109: argparse subparsers are once again not required by default (
…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

bpo-33109: argparse subparsers are once again not required by default (
…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>

thalerj added a commit to thalerj/openbmc-tools that referenced this pull request Jul 16, 2018

Fix Issue openbmc#21
This issue arises when running several different subcommands on some
versions of python, specifically the argparse module. A change was made
in the argparse module, making subparsers optional. More details are
documented here: python/cpython#3027 and here:
python/cpython#6919. The solution provided in
this fix will work with the argparse modules before and after a fix was
created. The following functions were impacted by this change: fru,
sensors, sel, dump, and firmware.

Signed-off-by: Justin Thaler thalerj@us.ibm.com

thalerj added a commit to thalerj/openbmc-tools that referenced this pull request Jul 20, 2018

Fix Issue openbmc#21
This issue arises when running several different subcommands on some
versions of python, specifically the argparse module. A change was made
in the argparse module, making subparsers optional. More details are
documented here: python/cpython#3027 and here:
python/cpython#6919. The solution provided in
this fix will work with the argparse modules before and after a fix was
created. The following functions were impacted by this change: fru,
sensors, sel, dump, and firmware.

Signed-off-by: Justin Thaler thalerj@us.ibm.com

thalerj added a commit to thalerj/openbmc-tools that referenced this pull request Jul 20, 2018

Fix Issue openbmc#21
This issue arises when running several different subcommands on some
versions of python, specifically the argparse module. A change was made
in the argparse module, making subparsers optional. More details are
documented here: python/cpython#3027 and here:
python/cpython#6919. The solution provided in
this fix will work with the argparse modules before and after a fix was
created. The following functions were impacted by this change: fru,
sensors, sel, dump, and firmware.

Signed-off-by: Justin Thaler thalerj@us.ibm.com

lisroach added a commit to lisroach/cpython that referenced this pull request Sep 10, 2018

bpo-33109: argparse subparsers are once again not required by default (
…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.

yahya-abou-imran added a commit to yahya-abou-imran/cpython that referenced this pull request Nov 2, 2018

bpo-33109: argparse subparsers are once again not required by default (
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.