Author rgov
Recipients bethard, mblahay, paul.j3, rgov
Date 2019-05-27.23:45:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1559000733.39.0.425100882803.issue35495@roundup.psfhosted.org>
In-reply-to
Content
Thanks Michael for all of the examples. After reading them all, I concur that "it can be hard to conceptualize what the exact behavior should be." A documentation change is warranted, at the least.

However the argparse documentation, while great, is dense and it would be easy to overlook a simple comment. And I think the point that is being raised isn't merely a suggestion on how to design a good CLI, but a pitfall that makes the behavior of code non-obvious---it's not something someone would necessarily consult the documentation for while reviewing code.

(By the way, I'm considering CLIs like `docker run` and `ssh` which take an optional command to execute, and when absent, fall back on default behavior.)

So I would prefer a code change that makes it harder to write code that hits this corner case. Potential solutions would be either

(a) making a positional REMAINDER arg with a default value an error, as in Paul's proposed change; or
(b) making a default value with a positional REMAINDER arg 'just work'

I think (a) is the most reasonable. The exception can recommend the use of nargs='*' instead, which makes it actionable. And it is unlikely that the exception would be buried down some untested code path that would end up in released code.

(Perhaps it's also worth raising an exception when adding a positional argument after a nargs>1 positional argument already exists, but that's another issue.)
History
Date User Action Args
2019-05-27 23:45:33rgovsetrecipients: + rgov, bethard, paul.j3, mblahay
2019-05-27 23:45:33rgovsetmessageid: <1559000733.39.0.425100882803.issue35495@roundup.psfhosted.org>
2019-05-27 23:45:33rgovlinkissue35495 messages
2019-05-27 23:45:33rgovcreate