[issue9694] argparse required arguments displayed under "optional arguments"

Miro Hrončok added the comment: https://bugs.python.org/issue42870 -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue9694] argparse required arguments displayed under "optional arguments"

paul j3 added the comment: Since this issue is closed it might be a good idea to open a new one with this problem. And if possible identify the failed tests. We forgot to allow for the fact that working code/tests might be checking for specific help messages, checks the will fail when

[issue9694] argparse required arguments displayed under "optional arguments"

Miro Hrončok added the comment: Coudl this please be mentioned on https://docs.python.org/3.10/whatsnew/3.10.html ? At least two packages fail tests because of the change (ipython and sphinxcontrib-autoprogram). -- nosy: +hroncok ___ Python

[issue9694] argparse required arguments displayed under "optional arguments"

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue9694] argparse required arguments displayed under "optional arguments"

Raymond Hettinger added the comment: New changeset 41b223d29cdfeb1f222c12c3abaccc3bc128f5e7 by Raymond Hettinger in branch 'master': bpo-9694: Fix misleading phrase "optional arguments" (GH-23858) https://github.com/python/cpython/commit/41b223d29cdfeb1f222c12c3abaccc3bc128f5e7 --

[issue9694] argparse required arguments displayed under "optional arguments"

Eric V. Smith added the comment: I wouldn't let breaking these tests deter you from improving the output. I think using "options" is an improvement. -- ___ Python tracker ___

[issue9694] argparse required arguments displayed under "optional arguments"

Raymond Hettinger added the comment: Since this change will break tests that rely matching help output exactly, I would like to hear if there are any objections to replacing "optional arguments" with "options". The words "switch" or "flag" don't work as well because they imply on/off and

[issue9694] argparse required arguments displayed under "optional arguments"

Change by Martin Burger : -- nosy: -mburger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9694] argparse required arguments displayed under "optional arguments"

Raymond Hettinger added the comment: I also like Eric'c suggestion of just using "options:" instead of "optional arguments". -- ___ Python tracker ___

[issue9694] argparse required arguments displayed under "optional arguments"

Raymond Hettinger added the comment: Since any chance to the help output will likely break tests, marking this as 3.10 only. -- components: +Library (Lib) -Documentation versions: -Python 3.9 ___ Python tracker

[issue9694] argparse required arguments displayed under "optional arguments"

Change by Raymond Hettinger : -- pull_requests: +22723 pull_request: https://github.com/python/cpython/pull/23858 ___ Python tracker ___

[issue9694] argparse required arguments displayed under "optional arguments"

Change by Raymond Hettinger : -- components: +Documentation type: enhancement -> behavior ___ Python tracker ___ ___

[issue9694] argparse required arguments displayed under "optional arguments"

Raymond Hettinger added the comment: Based on the attached survey of practices, I propose a minimal edit to the help display. Instead of "optional arguments:", we say "the options are as follows:". The use of the word "option" is dominant is in the CLI world, followed by "action" and

[issue9694] argparse required arguments displayed under "optional arguments"

Change by Raymond Hettinger : Added file: https://bugs.python.org/file49692/argparse_optional.txt ___ Python tracker ___ ___

[issue9694] argparse required arguments displayed under "optional arguments"

Change by Raymond Hettinger : -- Removed message: https://bugs.python.org/msg374042 ___ Python tracker ___ ___ Python-bugs-list

[issue9694] argparse required arguments displayed under "optional arguments"

Raymond Hettinger added the comment: I'll put together a patch this week to address the terminology problem. -- assignee: docs@python -> rhettinger priority: normal -> low versions: +Python 3.10, Python 3.9 -Python 3.6 ___ Python tracker

[issue9694] argparse required arguments displayed under "optional arguments"

Krzysiek added the comment: It seems the discussion has so far revolved around 'optional' arguments with `required=True`. What about the other way around? While trying to set `required=False` for a positional argument raises an exception, it is still possible to make the positional

[issue9694] argparse required arguments displayed under "optional arguments"

Géry added the comment: I have just run into the same issue here: https://bugs.python.org/issue38950 - I prefer Terry J. Reedy's "keyword arguments" as it is clear and consistent with "positional arguments". - But Steven Bethard 's "flag arguments" looks fine since it is well known to shell

[issue9694] argparse required arguments displayed under "optional arguments"

paul j3 added the comment: Mark, Have you tried defining your own Argument Group? If that didn't work, what fix do you want? Why? -- ___ Python tracker ___

[issue9694] argparse required arguments displayed under "optional arguments"

Mark Grandi added the comment: Is there anything that can be done to help this issue move along? I just ran into it just now -- nosy: +markgrandi ___ Python tracker ___

[issue9694] argparse required arguments displayed under "optional arguments"

Jack added the comment: I'd like to note that this also happens with a required mutually exclusive group: group = parser.add_mutually_exclusive_group(required=True) The arguments in the group are listed under “optional arguments:”. I'm guessing the mechanism is the same. -- nosy:

[issue9694] argparse required arguments displayed under "optional arguments"

Martin Panter added the comment: Posting argparse_option.v2.patch, which is minimally complete version of Ryan’s patch. I have dropped all the nonessential code and documentation tweaks. I also added a What’s New entry. I’d like to know if people think this is the right direction to move in.

[issue9694] argparse required arguments displayed under "optional arguments"

Martin Panter added the comment: I am willing to drop most of the code and comment changes if that moves us closer to consensus. Paul: would you accept changing the heading “optional arguments” to “options” in 3.6? I thought we were close to consensus to use “options”, but maybe that is my

[issue9694] argparse required arguments displayed under "optional arguments"

paul j3 added the comment: I can see changing the group title from 'optional arguments' to 'options' or 'optionals' parser._optionals.title 'optional arguments' But I don't think there's a need to change references in the code or its comments from 'optionals' to 'options'. I like

[issue9694] argparse required arguments displayed under "optional arguments"

Martin Panter added the comment: Still applicable to Python 3 AFAIK -- versions: +Python 3.5, Python 3.6 ___ Python tracker ___

[issue9694] argparse required arguments displayed under "optional arguments"

paul j3 added the comment: This ArgumentDefaultHelpFormatter issue should probably be raised in its own issue. It applies to 'required' optionals, but any patch would be independent of the issues discussed here. This class defines a method that adds the '%(default)' string to the help in

[issue9694] argparse required arguments displayed under "optional arguments"

Shahar Golan added the comment: This is not just a section issue. Please note that using the ArgumentDefaultHelpFormatter: argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultHelpFormatter) The help will also show (default=None) for these required arguments. --

[issue9694] argparse required arguments displayed under "optional arguments"

Changes by tony gaetani : -- nosy: +tonygaetani ___ Python tracker ___ ___

[issue9694] argparse required arguments displayed under "optional arguments"

Changes by Albert White : -- nosy: +Albert White ___ Python tracker ___ ___

[issue9694] argparse required arguments displayed under optional arguments

Martin Panter added the comment: Is there any interest in my or Ryan’s patches, which change the default heading away from “optional arguments”? Changing the default is my preferred fix, but if others don’t like it (e.g. compatibility concerns), I am happy to work on a documentation patch

[issue9694] argparse required arguments displayed under optional arguments

Martin Panter added the comment: Updated my patch with a “version changed” notice -- Added file: http://bugs.python.org/file37505/option-internal.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694

[issue9694] argparse required arguments displayed under optional arguments

Martin Panter added the comment: Here is much larger patch in the spirit of Ryan’s, that fixes the documentation, adjusts the tests, and some of the internal comments and variable names in the source code as well. However if some changes are too controversial, I am happy to simplify it to

[issue9694] argparse required arguments displayed under optional arguments

Ryan Hartkopf added the comment: Personally, 'options' is the first word that comes to mind other than 'arguments' (which is confusing for obvious reasons). But I think we can all agree that any of these candidates are less ambiguous than 'optional arguments'! It's been 4 years, let's put

[issue9694] argparse required arguments displayed under optional arguments

Oliver Smith added the comment: The term optional arguments is a poorly formed adjectival suffix of option. What it's trying to say is these are kwargs rather than these arguments are not compulsory. I ran into this issue with 3.4 and was looking to file a simple change request: In early

[issue9694] argparse required arguments displayed under optional arguments

Terry J. Reedy added the comment: To me, the mistake is contrasting 'positional' versus 'optional'. The proper contrasts are 'positional' versus 'named' or 'keyword' -- I believe these are mutually exclusive for command lines -- and 'required' versus 'optional. The two axes (contrasts) are

[issue9694] argparse required arguments displayed under optional arguments

R. David Murray added the comment: In unix parlance, they are arguments and options (or, sometimes, flags). And then required or not required. So, argparse follows unix precedent here, except that it calls them optional arguments, because everything is added via add_argument. Which is why

[issue9694] argparse required arguments displayed under optional arguments

paul j3 added the comment: The attached file shows how the default argument groups could be redefined, using 'required' as the criteria. I've implemented it as a method that is added to a subclass of ArgumentParser. This method is invoked after arguments are defined, prior to generating the

[issue9694] argparse required arguments displayed under optional arguments

paul j3 added the comment: Here's another possible solution: add a `help_groups` parameter to ArgumentParser. It is a list of base argument group names. `parser.add_argument(...)' places the action in one of those groups. This is a generalization of the current code which creates two groups

[issue9694] argparse required arguments displayed under optional arguments

Changes by paul j3 ajipa...@gmail.com: Added file: http://bugs.python.org/file34074/alt_grouping2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___

[issue9694] argparse required arguments displayed under optional arguments

Raymond Hettinger added the comment: How about calling required arguments required arguments? ... Clear and unambiguous. With this approach the user does not have to bloat the help to state This is required. +1 This is straight-forward, logical, and easy-to-read. -- nosy:

[issue9694] argparse required arguments displayed under optional arguments

paul j3 added the comment: As Steven pointed out, the existing `add_argument_group` mechanism can be used to group required arguments. For example - temp.py -- parser = argparse.ArgumentParser(description = 'Do something') group1 =

[issue9694] argparse required arguments displayed under optional arguments

Martin d'Anjou added the comment: How about calling required arguments required arguments? required arguments: --reqarg REQARG, -r REQARG This is required optional arguments: -h, --helpshow this help message and exit --optarg OPTARG, -o OPTARG

[issue9694] argparse required arguments displayed under optional arguments

Changes by paul j3 ajipa...@gmail.com: -- nosy: +paul.j3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___ ___ Python-bugs-list mailing list

[issue9694] argparse required arguments displayed under optional arguments

Changes by Martin Burger m...@rtin-burger.net: -- nosy: +mburger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___ ___ Python-bugs-list

[issue9694] argparse required arguments displayed under optional arguments

Steven Bethard steven.beth...@gmail.com added the comment: I'm changing the title because I keep seeing duplicates. Documentation patches still welcome! -- title: argparse: Default Help Message Lists Required Args As Optional - argparse required arguments displayed under optional