Message314152
On 03/20/2018 04:38 PM, Anthony Sottile wrote:
>
> Anthony Sottile <asottile@umich.edu> 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 https://bugs.python.org/issue9253 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: https://stackoverflow.com/a/23354355/812183) (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: https://bugs.python.org/issue29298
>
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 <report@bugs.python.org>
> <https://bugs.python.org/issue33109>
> _______________________________________
> |
|
Date |
User |
Action |
Args |
2018-03-20 16:25:49 | wolma | set | recipients:
+ wolma, bethard, eric.araujo, memeplex, paul.j3, Anthony Sottile |
2018-03-20 16:25:49 | wolma | link | issue33109 messages |
2018-03-20 16:25:49 | wolma | create | |
|