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 wolma
Recipients Anthony Sottile, bethard, eric.araujo, memeplex, paul.j3, wolma
Date 2018-03-20.16:25:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 03/20/2018 04:38 PM, Anthony Sottile wrote:
> Anthony Sottile <> added the comment:
> The intention of the change in issue 26510 was to pick the least surprising behaviour for the default value of subparsers -- the compatiblity with the behaviour before the regression was introduced in 3.3 was a nice side-effect.  As with the rest of positional arguments in argparse, the positional subparsers were changed to required by default.

Since the 3.3 change happened a long time ago and has been kept through 
the next three releases, I never considered it a regression, but rather 
thought the original behavior was an oddity of early Python 3s (I've 
never written an argparse-based parser in Python 2), so it's interesting 
to see this in the larger historical context.

Overall, I think "least surprising" is in the eye of the beholder here 
and I want to emphasize that I'm all for your change of adding the 
keyword argument, just not so convinced about your choice of the default.

My main argument for a default of False and against True: having True as 
the default will only lead people used to the Python 2 and pre-3.3 way 
of things to think that they have code working for Python 3, when, in 
fact, that code will break under 3.3-3.6, and, at least, 3.6 will stay 
in widespread use for a long time (even Ubuntu 18.04 will still ship 
with it as the default python3, so Python3.6 will outlast the life cycle 
of Python 2 by a good measure).
Conversely, most projects are dropping Python 3.2 support these days or 
have done so already, so nobody really cares about how things worked in 
this version (I think it's telling along these lines that your - 
corrected - SO link dates back from 2013). So I think, it is
a rather unnecessary incompatibility you are introducing for project 
maintainers even if the original issue was a regression.

> The main issue addressing the 3.3 regression I believe is and not the one linked.
> When I revived the patch, I surveyed a number of open source tools using subparsers (~10-20) and they all fell into the following categories:
> - Used the workaround (part of this SO post: (most fell into this category)
> - crashed with some sort of TypeError (NoneType has no attribute startswith, KeyeError: None, etc.) due to not handling "optional" subparsers
> - Manually handled when the subparser was `None` to raise an argparse error

As yet another option, and similar to the third one on your list, I'm 
using the set_defaults method of the subparser, and I'm checking whether 
the corresponding key is present in the Namespace.

> You can enable a 3.3-3.7 compatible "always optional subparsers" with a similar pattern that was used to manually restore the pre-regression behaviour:
> subparsers = parser.add_subparsers(...)
> subparsers.required = False

Ah, right! That's a good option. Didn't realize it would work this way, 
too :)

But a still think you should consider my above argument.

> I believe the error message issue is already tracked:

I see, that looks as if it would fix this part. It would be great if it 
could get merged into Python 3.7 still.

> ----------
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2018-03-20 16:25:49wolmasetrecipients: + wolma, bethard, eric.araujo, memeplex, paul.j3, Anthony Sottile
2018-03-20 16:25:49wolmalinkissue33109 messages
2018-03-20 16:25:49wolmacreate