Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment:
On 03/20/2018 04:38 PM, Anthony Sottile wrote: > > Anthony Sottile <asott...@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 <rep...@bugs.python.org> > <https://bugs.python.org/issue33109> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33109> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com