[issue46101] argparse: using parents & subcommands, options can be ignored
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46058] argparse: arg groups and mutually exclusive groups behave inconsitently
paul j3 added the comment: At least until these latest deprecations, the only nesting that made sense was to put a mutually_exclusive_group inside an argument_group. This was a way of providing a title and description for the exclusive_group. (And not documented.) I don't know if that's still possible. 'required' only makes sense for the exclusive_group. I don't know what happens when one tries to give it to an argument_group. If it doesn't raise an error, I expect it to be ignored. argument_groups are only used for help formatting; they have no role in parsing. exclusive_groups are primarily a parsing checking tool. Usage formatting tries to display exclusive groups, but is easily broken. While mutually_exclusive_group is a subclass of argument_group (and that in turn a subclass of argument_container), very little usage or behavior is inherited. Don't expect any consistency. A key point, that is easily lost, is that all groups share the _actions list with the parser. When an argument is added a group (either kind), it is, in effect, added to the parser's _actions list. So when parsing, there's only one list of Actions. A group will also keep the Action in its own _group_actions list, which is used for formatting or for exclusive checking. But otherwise the _group_actions list not used for parsing. Another point, is that there are 2 default argument_groups. Thus every Action is in an _group_actions list. If an exclusive_group is not nested in an argument_group, its Actions will be added to one of the defaults (optionals or positionals). -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46057] argparse: embedded groups may prevent options from being in help output
paul j3 added the comment: Don't add an argument_group to another argument_group. While input allows this nesting, the formatting is not designed to handle it. Nor does the documentation illustrate such nesting. Nesting a mutually_exclusive_group in an argument_group works because the exclusive_group is not used in formatting the help lines. The two class of groups have very different purposes. Note that the add_argument_group() method is defined for the parent _ActionsContainer class. ArgumentParser inherits from this, as do both of the group classes. While one could make a case for changing the group's inheritance of this method to Not-implemented, it's only a problem when users, like you, try to push for undocumented usage. In general argparse has a clean and powerful class structure. But it doesn't do a lot of checking and pruning, so there loose ends like this. The Action class and its subclasses is similarly powerful, with enough loose ends to allow adventurous users to hang themselves :). -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46101] argparse: using parents & subcommands, options can be ignored
paul j3 added the comment: This patch should be rejected. By using `common_opts_parser` as parent to both the main and subparsers, you have defined the same argument in both. By a long standing patch, the value assigned in the subparser has precedence (whether it's the default or user supplied). https://bugs.python.org/issue9351 argparse set_defaults on subcommands should override top level set_defaults Partial retraction of this override has been explored, but any changes are still up for debate https://bugs.python.org/issue45235 argparse does not preserve namespace with subparser defaults The bottom line is that we should not try to define the same argument (or more specifically the same `dest`) in both main and subparsers. Duplicate flags are ok. But resolving the conflicting values should be done after parsing. Some users will want to give priority to the main parser's values, others to the subparser's. Or their own defaults. argparse cannot handle all cases cleanly. -- ___ Python tracker <https://bugs.python.org/issue46101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46057] argparse: embedded groups may prevent options from being in help output
paul j3 added the comment: "I tried to create a group hierarchy in a way that I can pass the responsibility of argument validation to the argument parser." I looked at your example in: https://bugs.python.org/issue46058 The many levels of nesting groups was confusing, but now I realize that by nesting argument_groups in a mutually_exlusive_group you were try to implement some sort of any/all group within the xor group. This cannot be done within argparse. Mutually_exclusive only implements a flat xor. Argument_groups are used for help display, but play no role in parsing. Some years ago I explored the use of nest parsing groups: https://bugs.python.org/issue11588 Add "necessarily inclusive" groups to argparse I was trying to allow for nested groups that implemented all logical options - xor, or, and, not. Defining such groups wasn't hard. And I think I got the testing logic working right. But usage display required too big of a change to the formatter, and left too many loose ends. So I have let that languish. Now I recommend focusing on doing the testing after parsing. Use meaningful defaults where possible, and use `is None` to test whether a users has provided a value or not. -- ___ Python tracker <https://bugs.python.org/issue46057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46440] ArgumentParser.parse_args exits on missing required argument with exit_on_error=False
paul j3 added the comment: Duplicate of https://bugs.python.org/issue41255 Argparse.parse_args exits on unrecognized option with exit_on_error=False -- nosy: +paul.j3 resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46440> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46080] argparse.BooleanOptionalAction with default=argparse.SUPPRESS and help specified raises exception
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46101] argparse: using parents & subcommands, options can be ignored
Change by paul j3 : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46228] argparse docs: default for prog= in ArgumentParser() should be basename of argv[0], not argv[0], to match behaviour
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12954] Multiprocessing logging under Windows
New submission from paul j3 : The Windows programming guidelines for the multiprocessing module documentation should include a warning that any logging initialization should be protected by the 'if __name__' block. Otherwise you will get duplicate logging entries for the child processes. This is because the multiprocessing.forking.prepare() function explicitly calls log_to_stderr(), and may implicitly do so again when it imports the parent module, resulting in duplicate logging handlers. -- assignee: docs@python components: Documentation messages: 143815 nosy: docs@python, paul.j3 priority: normal severity: normal status: open title: Multiprocessing logging under Windows ___ Python tracker <http://bugs.python.org/issue12954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47002] argparse - "expected one argument" when used -: in argument
paul j3 added the comment:
'-1' and '-1.23' are recognized as numbers, and treated as arguments. '-1'
requires some special handling because it is allowed as a flag, as in
parser.add_argument('-1','--one')
'-1:00' on the other hand is no different from a string like '-foo'. Default
is to parse it as a flag. If you don't get this error
argument -f: expected one argument
you are likely to get:
error: unrecognized arguments: -1:23
This can probably be closed as a duplicate of:
https://bugs.python.org/issue9334
argparse does not accept options taking arguments beginning with dash
(regression from optparse)
--
___
Python tracker
<https://bugs.python.org/issue47002>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25299] TypeError: __init__() takes at least 4 arguments (4 given)
paul j3 added the comment: I'm not set up to work with the current development distribution (via github). All my proposed patches are diffs for earlier repos. Paul -- ___ Python tracker <https://bugs.python.org/issue25299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9350] add remove_argument_group to argparse
paul j3 added the comment: hai shi Do you have a specific need for this, or do you want it just for the same of completeness? -- ___ Python tracker <https://bugs.python.org/issue9350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16468] argparse only supports iterable choices
paul j3 added the comment: But see https://bugs.python.org/issue37793 for a discussion of whether 'container' is as good a descriptor as 'iterable'. -- ___ Python tracker <https://bugs.python.org/issue16468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37910] argparse wrapping fails with metavar="" (no metavar)
paul j3 added the comment: That usage formatting is extremely brittle. It's not just "" metavar that can mess it up. Other 'usual' characters can mess it in the same way. The underlying problem is that it formats the whole usage, and if it is too long tries to split it into pieces, and then reassemble it in wrapped lines. The assertion tries to verify that the split was accurate. Usage really needs to be rewritten in a way that keeps the individual Action pieces separate until it is ready to assemble them into final lines. Anything else is just bandaids. -- ___ Python tracker <https://bugs.python.org/issue37910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
paul j3 added the comment: https://bugs.python.org/issue26510 https://bugs.python.org/issue33109 There was some flip/flop over whether required should be true by default or not - the current behavior is False, (the 3.3.0) The lasting change since this issue in 2012 is that `add_subparsers` now takes the 'required' parameter. And this is documented. To avoid the problem raising in this issue, the subparsers should be defined with: p1 = parser.add_subparsers(required=True, dest='cmd') The 'dest' parameter is documented, but that fact that it is needed with required=True is not. Without it you can get an error when missing-argument is being formatted. Without it the error formatter doesn't know what to call this argument. I've mentioned this in one or more issues. See my SO answer for discussion on this: https://stackoverflow.com/questions/23349349/argparse-with-required-subparser/23354355#23354355 -- ___ Python tracker <https://bugs.python.org/issue16308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27227] argparse fails to parse [] when using choices and nargs='*'
Change by paul j3 : -- nosy: +paul.j3 status: closed -> open ___ Python tracker <https://bugs.python.org/issue27227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38217] argparse should support multiple types when nargs > 1
paul j3 added the comment: Which is more valuable to you, the string conversion, or the checking? What's wrong with doing the 'type check' in post parsing code? (MarSoft's answer in the SO link). To make a better case for this, I'd suggest writing your own fix. It doesn't need to be a polished push, but enough code to show that the change is relatively simple (preferably occurring in only one or two functions). -- ___ Python tracker <https://bugs.python.org/issue38217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38584] argparse: Specifying a whitespace-only help message to a positional arg triggers an IndexError when displaying --help
paul j3 added the comment:
So the error occurs in HelpFormatter._format_action when 'help_lines' is an
empty list:
if action.help:
help_text = self._expand_help(action)
help_lines = self._split_lines(help_text, help_width)
>> parts.append('%*s%s\n' % (indent_first, '', help_lines[0]))
for line in help_lines[1:]:
parts.append('%*s%s\n' % (help_position, '', line))
It occurs with both optionals and positionals. It does not occur with
argparse.RawTextHelpFormatter.
The default _split_lines:
def _split_lines(self, text, width):
text = self._whitespace_matcher.sub(' ', text).strip()
return _textwrap.wrap(text, width)
Because of the 'strip' it treats a help with space as empty
In [27]: f._split_lines('',40)
Out[27]: []
In [28]: f._split_lines('test',40)
Out[28]: ['test']
In [29]: f._split_lines(' ',40)
Out[29]: []
None or '' don't trigger this because they are weeded out by the 'if
action.help:' line.
Maybe the change proposed here, to skip the problem line if 'help_lines' is
empty is the right one. Assuming a list is non-empty can be dangerous. But it
would be wise to test the patch with the alternative formatters like the
RawText.
It may also be worth thinking about correcting the issue in _split_lines(),
which is shorter. The only difference in RawTextHelpFormatter is in this
method.
--
___
Python tracker
<https://bugs.python.org/issue38584>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38438] argparse "usage" overly-complex with nargs="*"
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue38438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38584] argparse: Specifying a whitespace-only help message to a positional arg triggers an IndexError when displaying --help
paul j3 added the comment: Just today on SO someone found a similar bug in the help format with metavars, that involved an unpacking the expected only one value, but got 2. https://stackoverflow.com/questions/58541460/tuple-metavar-value-for-positional-argument-with-nargs-1 This had be raise years ago, as https://bugs.python.org/issue14074 -- ___ Python tracker <https://bugs.python.org/issue38584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36664] argparse: parser aliases in subparsers stores alias in dest variable
paul j3 added the comment: Just clarify how the code currently works. `subparsers` is a positional Action of subclass _SubParsersAction. It has a nargs='+...', requiring at least one string, and taking all remaining strings. Its __call__ has the standard signature. So everything that's special about subparsers is embodied in this Action subclass. def __call__(self, parser, namespace, values, option_string=None): parser_name = values[0] arg_strings = values[1:] # set the parser name if requested if self.dest is not SUPPRESS: setattr(namespace, self.dest, parser_name) # select the parser try: parser = self._name_parser_map[parser_name] ... So the `parser_name` is first string, the actual alias that user provided. It is added to the namespace if a `dest` was provided (the default `dest` is SUPPRESS). That's all of the relevant code - the alias is simply added to to Namespace. As mentioned before `parser_name` is used find the actual sub parser, which is called with the remaining `arg_strings`. Earlier in the subclasses `add_parser` method, the 'name' and 'alias' list are used to populate the '_name_parser_map' mapping, and also create the metavar that's used in the help display. But neither is saved as an attribute. --- I still think 'set_defaults' is the cleanest way of saving a unique name for a sub parser. parser_foo.set_defaults(func=foo, name='foo') --- One further note - if you make subparsers required, you should also set a dest name: parser.add_subparsers(dest='cmd', required=True) otherwise the missing-subparsers error message will raise an error. It needs to identify the missing action in some way. Functionally, this might be the most important reason to set the 'dest'. -- ___ Python tracker <https://bugs.python.org/issue36664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11354] argparse: nargs could accept range of options count
paul j3 added the comment:
A couple of quick observations:
- this is one of the first patches that I worked on, so the details aren't
fresh in my mind. A glance at my latest patch show that this isn't a trivial
change.
- nargs changes affect the input handling, the parsing, help and usage
formatting, and error formatting. As a result, nargs are referenced in several
places in the code. That complicates maintenance and the addition of new
features. Help formatting is particularly brittle; just look at the number of
issues that deal with 'metavar' to get a sense of that.
- At one point I tried to refactor the code to consolidate the nargs handling
in a few functions. I don't recall if I posted that as a patch.
- The first posts on this topic suggested a (n,m) notation; I proposed a regex
like {n,m}. There wasn't any further discussion.
- Note that the initial posts were in 2011 when Steven (the original author)
was involved. I posted in 2013. There hasn't been any further action until
now. I don't recall much interest in this topic on Stackoverflow either. So
my sense is that this isn't a pressing issue.
- It's easy to test for this range after parsing, with '*' or '+' nargs. So
the main thing this patch adds is in the help/usage display. It doesn't add
significant functionality.
- cross links:
https://bugs.python.org/issue9849 - Argparse needs better error handling for
nargs
https://bugs.python.org/issue16468 - argparse only supports iterable choices
(recently closed)
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue11354>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38590] argparse unexpected behavior with argument group inside mutually exclusive group
paul j3 added the comment: With one exception, groups are not designed or intended to be nested. But by inheritance (from _ActionsContainer) nesting isn't blocked nor does it raise any errors. As you surmise, an ArgumentGroup, is used only for grouping the help lines. By default that are two groups, with 'optionals' and 'required' names (actually the later should be 'positional'). The rest are user defined. They don't affect parsing in any way. MutuallyExclusiveGroup is used in parsing. It also is used, to the extent possible, when formatting usage. If a MutuallyExclusiveGroup is nested inside another MutuallyExclusiveGroup the parsing effect is just one flat group. Usage can be messed up - that's been the subject of another bug/issue. A MutuallyExclusiveGroup may be put in an ArgumentGroup. This is a way of giving the exclusive group a title and/or description in the help. There is a bug/issue requesting some sort of inclusive group. I tried to develop such a patch, implementing nesting, complete logic control (not just the current xor). But the usage formatting needs a complete rewrite. Overall this is too complex of an addition. On StackOverFlow I tell people to implement their own post-parsing testing. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue38590> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38736] argparse: wrong type from get_default when type is set
paul j3 added the comment: get_default just returns the default attribute as it is stored in the Action. Defaults are stored as given. During parsing the Action's default is placed in the args namespace at the start. At the end, it checks if the value in the namespace is a string that matches the default (i.e. has been over written by user input). Only then is it passed through the type function. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue38736> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43220] Argparse: Explicit default required arguments with add_mutually_exclusive_group are rejected
paul j3 added the comment: An overlapping issue https://bugs.python.org/issue18943 argparse: default args in mutually exclusive groups That issue shows that this problem arises with small integers as well (<257), which in cpython have unique ids. It's an implementation detail, pypy for example does not have this issue. The whole purpose of this extra default testing is to allow '?/*' positionals in mutually_exclusive_groups. The patch I proposed in 2013 is basically the same thing, except I called the new flag variable 'using_default'. We should review the discussion in that issue to see if it raises any additional issues or concerns. -- ___ Python tracker <https://bugs.python.org/issue43220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43874] argparse crashes on subparsers with no dest/metava
paul j3 added the comment: This is a well known (if not fixed) issue - if subparsers is required, then a dest is needed to give a working error message. Looks like we've variously talked about documenting the requirement, or using some sort of substitute for the missing name. One of my higher-voted SO answers: https://stackoverflow.com/questions/23349349/argparse-with-required-subparser/23354355#23354355 https://bugs.python.org/issue29298 https://github.com/python/cpython/pull/18564 https://github.com/python/cpython/pull/3027 https://github.com/python/cpython/pull/3680 -- ___ Python tracker <https://bugs.python.org/issue43874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43876] argparse documentation contrasting nargs '*' vs. '+' is misleading
paul j3 added the comment:
Let's see if I can clarify somethings. But first, I should say that I've
worked with this code for so long, that I may miss things that could confuse a
beginner.
A basic distinction is between "optionals" and "positionals". I put those in
quotes because that's not the same as "required or not". Talk about "options"
in commandline arguments goes way back (see getopt, and optparse).
An "optional" is identified by a flag string, such as "-f" or "--foo", short or
long, single or double dash. I prefer to call these "flagged arguments".
"optionals" can occur in any order, and even repeatedly.
A "postional" is identified by position, without any sort of flag string. In
earlier parsers, these where the extras, the strings that weren't handled by
"options". These can only occur in the defined order.
Conventionally, optionals come first, and positionals at the end. That's how
most "help/usage" messages display them. But argparse tries to handle them in
any order.
Both kinds can take a "nargs" parameter. This specifies how many arguments (or
strings) are required, either following the flag string, or as part of
position. Obviously if you don't specify the flag, you don't have to provide
its arguments either.
There's another point of confusion. "parse.add_argument" creates an "Action",
also called an "argument". And each "action" has a 'nargs' that specifies how
many "arguments" go along with it. Sorry.
The default "nargs" value is "None", which means 1 string. "?" means zro or
one (optional, but in a different sense than flagged). "*" means any number.
"+" means one or more. nargs could also be a number, e.g. "2". There isn't
anything that specifies "2 or more" or "2 or 3" (though that has been
requested). "?+*" are used in basically the same sense as in regex/re patterns.
There's another parameter, "action", which also controls the number of required
strings. With "store_true" no string is allowed after the flag, effectively
"nargs=0" (this action makes no sense for positionals). It's actually of
subclass of "store_const", with a default "False" and const "True".
With a flagged argument, you may also specify a "required" parameter. That's
convenient, but does lead to confusing terminology. "optionals" may be
"required", and a "positional" with "?" is optional/not-required.
Since "+" and "*" allow many strings, something has to define the end of that
list. That end is either the end of the input, or the next flag string. If you
are just using flagged arguments this isn't a problem. But with "positionals",
it is hard to handle more than one open-end nargs. Or to use such a
"positional" after an open-ended "optional". As with regex, these nargs are
"greedy".
In some ways, the documentation is more complicated than the code itself. The
code is well written, with different methods and classes handling different
issues. The code itself does not have a lot of complicated rules and
conditions. The complexity comes from how the different pieces interact.
"flagged vs positional", nargs, and "required" are separate specifications,
though they do have significant interactions.
In your example:
parser.add_argument("outdata", help="Path to output data file")
parser.add_argument("plotTimes", nargs='*', help="Times to plot")
parser.add_argument("outplot", help="Path to output plot file")
"outdata" takes one string. "outplot" takes another. "plotTimes" then gets
anything left over in between. An empty list of strings satisfies its "nargs".
The strings are actually allocated with a regex expression.
With `arg_argument('--foo', nargs='+')`,
--foo one
--foo one two three
are both allowed. With "*",
--foo
is also allowed. For a "positional" omit the "--foo". That means that a
"positional" with "*" is always seen (which can require some special edge case
handling).
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue43876>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11354] argparse: nargs could accept range of options count
paul j3 added the comment: Post parsing testing for the correct number of strings is the easy part. It's the auto-generate usage that's harder to do right, especially if we wanted to enable the metavar tuple option. Clean usage for '+' is messy enough. -- ___ Python tracker <https://bugs.python.org/issue11354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43942] RawDescriptionHelpFormatter seems to be ignored for argument descriptions
paul j3 added the comment: You test with RawDescriptionHelpFormatter, but quote from the RawTextHelpFormatter. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue43942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43192] Argparse complains argument required when default is provided
paul j3 added the comment:
To a large degree the Action parameters operate independently. That is,
different parts of the code use the parameters for their own purposes. The
composite behavior is a result of those individual actors, rather than some
sort of overall coordinated plan.
First your Action is 'positional' (no flag string), and "store" type. nargs is
the default None. The only extra is the default value (the default default is
None).
_ActionsContainer._get_positional_kwargs processes such an argument, setting
the 'required' parameter with:
# mark positional arguments as required if at least one is
# always required
if kwargs.get('nargs') not in [OPTIONAL, ZERO_OR_MORE]:
kwargs['required'] = True
if kwargs.get('nargs') == ZERO_OR_MORE and 'default' not in kwargs:
kwargs['required'] = True
At the start of parsing, all 'default' values are added to the 'args' Namespace.
If an Action is "seen", either via the appropriate flag string, or a positional
value, it is added to the "seen_actions" list.
At the end of parsing, it iterates through all the '_actions'. If it is not in
the 'seen_actions' list, and is marked "required", it gets added to the
'reqiuired_action' error list.
So even though your Action has a 'default' it is still required. The default
is, in effect, ignored. The nargs value (default or not) has priority in
setting the 'required' value.
'?/*' nargs require special handling. This nargs requirement is satisfied by
an empty list. Such a positional will, in effect, always be seen. But if a
explicit default is provided, that will over write the empty list.
Handling defaults is inherently tricky. But except for the special '?/*' case,
specifying a 'default' with a positional doesn't make much sense.
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue43192>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44748] argparse: a bool indicating if arg was encountered
paul j3 added the comment:
Joker
'type=bool' has been discussed in other issues. 'bool' is an existing python
function. Only 'bool("")' returns False. Write your own 'type' function if
you want to test for specific strings. It's too language-specific to add as a
general purpose function.
--
___
Python tracker
<https://bugs.python.org/issue44748>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44748] argparse: a bool indicating if arg was encountered
paul j3 added the comment: I've explored something similar in https://bugs.python.org/issue11588 Add "necessarily inclusive" groups to argparse There is a local variable in parser._parse_known_args seen_non_default_actions that's a set of the actions that have been seen. It is used for testing for required actions, and for mutually_exclusive groups. But making it available to users without altering user API code is awkward. My latest idea was to add it as an attribute to the parser, or (conditionally) as attribute of the namespace https://bugs.python.org/issue11588#msg265734 I've also thought about tweaking the interface between parser._parse_known_args parser.parse_known_args to do of more of the error checking in the caller, and give the user more opportunity to do their checks. This variable would be part of _parse_known_args output. Usually though when testing like this comes up on SO, I suggest leaving the defaults as None, and then just using a if args.foobar is None: # not seen Defaults are written to the namespace at the start of parsing, and seen arguments overwrite those values (with an added type 'eval' step of remaining defaults at the end). Keep in mind, though, that the use of subparsers could complicate any of these tweaks. In reading my posts on https://bugs.python.org/issue26394, I remembered the IPython uses argparse (subclassed) with config. I believe it uses config inputs (default and user) to define the arguments for the parser. So unless someone comes up with a really clever idea, this is bigger request than it first impressions suggest. -- ___ Python tracker <https://bugs.python.org/issue44748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44748] argparse: a bool indicating if arg was encountered
paul j3 added the comment: More on the refactoring of error handling in _parse_known_args https://bugs.python.org/issue29670#msg288990 This is in a issue wanting better handling of the pre-populated "required" arguments, https://bugs.python.org/issue29670 argparse: does not respect required args pre-populated into namespace -- ___ Python tracker <https://bugs.python.org/issue44748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44748] argparse: a bool indicating if arg was encountered
paul j3 added the comment:
Another way to play with the defaults is to use argparse.SUPPRESS. With such a
default, the argument does not appear in the namespace, unless provided by the
user.
In [2]: p = argparse.ArgumentParser()
...: p.add_argument('--foo', default=argparse.SUPPRESS, help='foo help')
...: p.add_argument('--bar', default='default')
...: p.add_argument('--baz');
In [3]: args = p.parse_args([])
In [4]: args
Out[4]: Namespace(bar='default', baz=None)
Such a namespace can be used to update an existing dict (such as from a config
file), changing only keys provided by user (and ones where SUPPRESS does not
make sense, such as store_true and positionals).
In [5]: adict = {'foo':'xxx', 'bar':'yyy', 'baz':'zzz'}
In [6]: adict.update(vars(args))
In [7]: adict
Out[7]: {'foo': 'xxx', 'bar': 'default', 'baz': None}
User provided value:
In [8]: args = p.parse_args(['--foo','foo','--baz','baz'])
In [9]: args
Out[9]: Namespace(bar='default', baz='baz', foo='foo')
In this code sample I used Ipython. That IDE uses (or at least did some years
ago) a custom integration of config and argparse. System default config
file(s) set a large number of parameters. Users are encouraged to write their
own profile configs (using provided templates). On starting a session, the
config is loaded, and used to populate a parser, with arguments, helps and
defaults. Thus values are set or reset upto 3 times - default, profile and
commandline.
I for example, usually start an ipython session with an alias
alias inumpy3='ipython3 --pylab qt --nosep --term-title
--InteractiveShellApp.pylab_import_all=False
--TerminalInteractiveShell.xmode=Plain'
Regarding this bug/issue, if someone can come up with a clever tweak that
satisfies Thermi, is potentially useful to others, and is clearly backward
compatible, great.
But if this issue requires a less-than-ideal-compatible patch, or greater
integration of config and argparse, then it needs to be developed as a separate
project and tested on PyPi. Also search PyPi; someone may have already done the
work.
--
___
Python tracker
<https://bugs.python.org/issue44748>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44986] Date formats in help messages of argparse
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue44986> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44587] argparse BooleanOptionalAction displays default=SUPPRESS unlike other action types
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue44587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45110] argparse repeats itself when formatting help metavars
paul j3 added the comment: This is has been requested various times on StackOverflow, and possibly here (I'd have to do a search). The closest thing to making a compact action_invocation is to set the metavar to '', and even thing we get a space, eg. -f , --foo Help text This repeat has been a part of argparse from the beginning, so I can't see changing the default behavior. But we could add a HelpFormatter subclass that changes one (or two methods) such as _format_action_invocation. Subclassing the formatter is the accepted way of adding help features. I, and possibly others, must have suggested such a change on SO. Of course people can use such a subclass without it being part of the standard module. -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45110] argparse repeats itself when formatting help metavars
paul j3 added the comment: https://bugs.python.org/issue42980 argparse: GNU-style help formatter https://bugs.python.org/issue33389 argparse redundant help string https://bugs.python.org/issue29626 Issue with spacing in argparse module while using help https://bugs.python.org/issue27303 [argparse] Unify options in help output https://stackoverflow.com/questions/23936145/python-argparse-help-message-disable-metavar-for-short-options https://stackoverflow.com/questions/18275023/dont-show-long-options-twice-in-print-help-from-argparse -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45110] argparse repeats itself when formatting help metavars
paul j3 added the comment: The idea of combining help features by defining a subclass that inherits from other subclasses was endorsed by the original developer (we could dig up an old bug/issue to prove that). The provided subclasses all tweak a "private" method, often one that's buried deep in the calling stack. I can't quote any official policy, but my sense is that Python developers are ok with users subclassing and modifying "private" methods. Methods, functions and classes (and variables) with leading '_' aren't documented, or imported via `__all__`, but otherwise the boundary between what is part of the user API and what's "hidden" is loose in Python. Apparently some corporate policies prohibit use or modification of things that aren't in the public API, but I don't think that policy protects you from changes. 'argparse' changes at a glacial rate, with a lot of concern for backward compatibility. In fact it's that fear of unintended consequences that slows down the pace of change. Subclassing a help formatter is preferred because it minimizes the chance of hurting existing users. -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False
paul j3 added the comment: In https://stackoverflow.com/questions/69108632/unable-to-catch-exception-error-for-argparse we found that `exit_on_error` does not work when the error occurs in a subparser. Unless someone wants to take time to get this right, I think this feature should be removed. It's too buggy. -- ___ Python tracker <https://bugs.python.org/issue41255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False
paul j3 added the comment: In https://stackoverflow.com/questions/69108632/unable-to-catch-exception-error-for-argparse it looked like `exit_on_error` does not work when using subparsers. On on further thought, I realized that it has to included in the definition of the subparser. As with other `ArgumentParser` parameters, the subparsers does not inherit from the main parser. So it's basically a documentation issue. The `add_parser` method is described briefly as: which takes a command name and any ArgumentParser constructor arguments, and returns an ArgumentParser object that can be modified as usual. But as my experience shows, its relevance is easily missed, even by an experienced users. -- ___ Python tracker <https://bugs.python.org/issue41255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False
Change by paul j3 : -- Removed message: https://bugs.python.org/msg401554 ___ Python tracker <https://bugs.python.org/issue41255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24739] allow argparse.FileType to accept newline argument
paul j3 added the comment: Adding `newline` to `FileType` requires modifying both the `__init__` and `__call__` methods. That's nearly the whole class. I'd copy and edit, and forget about subclassing. -- ___ Python tracker <https://bugs.python.org/issue24739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45587] argparse add_argument_group: distinguish title and description from **kwargs
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41592] Make _SubParsersAction public
paul j3 added the comment: `add_argument` also returns a Action subclass object. All of those subclasses are "private". While that return reference is usually ignored, sometimes it is useful to it, assigning it to a variable or list. The documentation could be clearer about access to Action objects. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue41592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45580] argparse.ArgumentParser.add_mutually_exclusive_group : metavar create parenthesis undefined behavior
paul j3 added the comment: The usage formatting is fragile, with many associated bug reports. Until someone does a major rewrite, it is best to avoid special characters, especially `()` and `[]` in the `dest` or `metavar`. Usage uses () to encolde mutually_exclusive_groups and [] to mark non-required arguments. Don't confuse your users (or argparse) with other uses of these characters. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45275] Make argparse print description of subcommand when invoke help doc on subcommand
paul j3 added the comment:
Are you expecting the subcommand help to show the 'help' line that the main
help shows?
subparsers.add_parser('a', help='a help')
add_parser takes all of the parameters that `ArgumentParser` takes, including
description and epilog.
I don't think we need to add anything to add_parser.
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue45275>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45504] [argparse] Entering a partial config_parser flag works with subparsers
paul j3 added the comment: As a default option flags can be abbreviated (unless there's a conflict). Recent version have a allow_abbrev parameter that lets you turn this off. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45235] argparse does not preserve namespace with subparser defaults
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45235] argparse does not preserve namespace with subparser defaults
paul j3 added the comment: I haven't studied or tested this change, but it looks like a partial retraction of https://bugs.python.org/issue9351 argparse set_defaults on subcommands should override top level set_defaults Originally the main namespace was passed to the subparser. Steven Bethard changed it so that the subparser got a fresh namespace, and all values were copied to the main namespace. I and others raised the question of how it affected user provided values https://bugs.python.org/issue27859 argparse - subparsers does not retain namespace Looks like this patch tries to solve some problems by moving the self._defaults step to the end of parser_know_args. I view that change with some trepidation. Handling defaults is tricky enough, with setting them at the start, but then only passing them through 'type' at the end if they still match the original strings. Mostly I've been telling StackOverflow questioners that it best not to use the same argument 'dest' in both the main and subparsers. Flags can be the same, but the 'dest' should be different to avoid conflicts over which default has priority. Again, I haven't tested this change, but I have a gut feeling it could have backward compatibility issues. -- ___ Python tracker <https://bugs.python.org/issue45235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45235] argparse does not preserve namespace with subparser defaults
paul j3 added the comment: I just downloaded this `argparse.py`. This change makes it impossible to use a subparser argument if it is defined in the user provided namespace, or by the main parser. It blocks not only subparser default, but also user input. It has reverted the 9351 patch which dates to 2014. -- ___ Python tracker <https://bugs.python.org/issue45235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45235] argparse does not preserve namespace with subparser defaults
paul j3 added the comment:
parser = argparse.ArgumentParser()
sub = parser.add_subparsers()
example_subparser = sub.add_parser("example")
example_subparser.add_argument("--flag", default=10)
print(parser.parse_args(["example","--flag=15"],
argparse.Namespace(flag=20)))
still returns flag=20
User input should override values set by the provided Namespace.
--
___
Python tracker
<https://bugs.python.org/issue45235>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41592] Make _SubParsersAction public
paul j3 added the comment: A _SubParsersAction is private to the extent that users should not attempt to create it directly, and thus don't need to know the details - beyond what's documented: "The add_subparsers() method is normally called with no arguments and returns a special action object. This object has a single method, add_parser(), which takes a command name and any ArgumentParser constructor arguments, and returns an ArgumentParser object that can be modified as usual." All action objects have methods like __call__ and format_usage. The subparsers Action has other methods, but add_parser is the only new "public" method. There's a tension in writing documentation between getting all details just right, and providing just enough for most users. As it is, many new users are over whelmed by the documentation. My understanding is that the "private/public" designation is a convenience for users, and not enforced by Python developers. I gather though that some corporate users have policies that prohibit modification of "private" objects, supposedly due to a fear that Python could modify or eliminate those objects without proper notification. Somehow the "public" documentation sets that part of the code in stone. My experience here is that it's easier modify the documentation to fit the code than the other way around :) -- ___ Python tracker <https://bugs.python.org/issue41592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45235] argparse does not preserve namespace with subparser defaults
Change by paul j3 : -- stage: resolved -> test needed status: closed -> pending ___ Python tracker <https://bugs.python.org/issue45235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45504] [argparse] Entering a partial config_parser flag works with subparsers
Change by paul j3 : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34046] subparsers -> add_parser doesn't support hyphen char '-'
paul j3 added the comment: Артём Иконников, developers and experienced users are familiar with other programs, such as 'svn' which is used as an example svn checkout, svn update, and svn commit Also the use of '--foo' as flagged/optional(s) argument is so familiar to developers, that it does nor occur us that new users might want to use that form here. While there's no explicit prohibition of using the dash, non of the examples use it. Examples are a good starting place when using new features. If this problem came up more often, I'd recommend modifying the `add_parser` method to raise an error if the user provides a dashed command name (or alias). -- ___ Python tracker <https://bugs.python.org/issue34046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45631] missing unittests for overlapping dest when using subparsers
New submission from paul j3 : https://bugs.python.org/issue45235 argparse does not preserve namespace with subparser defaults was passed and put into the latest release with rather obvious buggy behavior. This means that the unittest file does not adequately test for overlapping 'dest' in the main and subparsers. It probably also does not test many (any?) cases of user provided namespace. Issue9351 added a test, but it only tested defaults set with parser.set_defaults(foo=1) xparser.set_defaults(foo=2) not the more common practice of setting defaults in add_argument. 45235 adds one test, but again only for xparser.set_defaults(foo=1) It doesn't test for user inputs, as with ['X','--foo=3'] -- messages: 405110 nosy: ALSchwalm, paul.j3, rhettinger priority: normal severity: normal stage: needs patch status: open title: missing unittests for overlapping dest when using subparsers ___ Python tracker <https://bugs.python.org/issue45631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45235] argparse does not preserve namespace with subparser defaults
paul j3 added the comment: I should study previous posts in more detail, but here are some thoughts on correctly handling user namespace. At the start of `parse_known_args`, there's a if namespace is None: namespace = Namespace() We need to hang on to a copy of this namespace, e.g. call it import copy orig_namespace = copy.copy(namespace) In _SubParsersAction.__call__, pass this copy to the subparser (instead of None): subnamespace, arg_strings = parser.parse_known_args(arg_strings, orig_namespace) for key, value in vars(subnamespace).items(): setattr(namespace, key, value) Prior to 9351, the main namespace was passed to the subparser namespace, arg_strings = parser.parse_known_args(arg_strings, namespace) The trick is to get orig_namespace from the main parse_known_args to SubParsersAction.__call__ method. in a 9351 post I explore the idea of allowing the user to specify a 'sub_namespace' for the subparser. https://bugs.python.org/msg230056 In any case, this is a complicated issue that needs careful thought and more extensive testing. I didn't entirely like the original 9351 change, but since that's been part of argparse for many years, we need to very careful about clobbering it. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue45235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9351] argparse set_defaults on subcommands should override top level set_defaults
paul j3 added the comment: A new patch, https://bugs.python.org/issue45235 has clobbered this patch. It has also exposed the inadequate unittesting for the case(s) where the 'dest' of main namespace, subparser namespace, user provided namespace overlap. -- ___ Python tracker <https://bugs.python.org/issue9351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45690] Argparse exclusive group inside required exclusive group displays incorrectly
paul j3 added the comment: There was a bug/issue that addressed problems with nested mutually_exclusive_groups. It should be easy to find. The problem is that the usage formatter is brittle, building a string and then striping out "unnecessary" characters. I assume the fix handled the default case (not required), but apparently it missed this variation. I wasn't too involved with that, since in my opinion nesting these groups is useless, and should be avoided. You might as well use one union group. Test the parsing for yourself. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45673] argparse error with option with optional value
paul j3 added the comment: This is too big of an example for this board; I think it should have been asked on StackOverFlow. Or maybe trimmed do to a more compact example. But in any case, this is normal behavior for argparse. Type checking, here 'int', is done after the string is allocated to the '-s' argument. Reserving that string for the required positional requires a form of look ahead that argparse does not currently do. I think there's an old bug/issue on the topic, but the fix was, if I remember correctly, too complex to simply drop in. I may look that up later. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45656] argparse bug: prefix_chars argument to add_argument_group doesn't really work
paul j3 added the comment: Use of 'prefix_chars' as a argument_group parameter is not documented, nor intended. If it does appear to work in the help formatting, it is probably the result of inheritance, since both ArgumentParser and Argument_group subclass a _Actions_Container class. I'd have to examine the code to see what's happening. Argument_groups are used only for help formatting, not for parsing. In any case, I don't think anything needs to be changed or fixed. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45690] Argparse exclusive group inside required exclusive group displays incorrectly
paul j3 added the comment: https://bugs.python.org/issue29553 Argparser does not display closing parentheses in nested mutex groups supposedly fixed the parentheses for nested groups. You can read its discussion and patches to see why it does not handle your case. I don't see any examples have required groups. [] is used for un-required, () for required. This patch did not change how the usage was generated. It just refined how excess [()] were removed. Proper handling of groups requires a major rewrite of the usage formatter. -- ___ Python tracker <https://bugs.python.org/issue45690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45656] argparse bug: prefix_chars argument to add_argument_group doesn't really work
paul j3 added the comment:
prefix_chars is a parameter of the parent _ActionsContainer
class _ActionsContainer(object):
def __init__(self,
description,
prefix_chars,
argument_default,
conflict_handler):
super(_ActionsContainer, self).__init__()
self.description = description
self.argument_default = argument_default
self.prefix_chars = prefix_chars
self.conflict_handler = conflict_handler
add_argument is also a method in this class. It uses its own prefix_chars to
categorize arguments as optional/positional
chars = self.prefix_chars
if not args or len(args) == 1 and args[0][0] not in chars:
see also _get_optional_kwargs method.
class _ArgumentGroup(_ActionsContainer):
inherits from _ActionsContainer, and usually gets the prefix_chars from its
container (the parser)
update('prefix_chars', container.prefix_chars)
The parser is created with
class ArgumentParser(_AttributeHolder, _ActionsContainer):
and documents the use of prefix_chars.
In addition to passing prefix_chars to its Super, it uses
default_prefix = '-' if '-' in prefix_chars else prefix_chars[0]
to define the -h help argument.
Early in parsing, args strings are categorized as 'O' or 'A'. That is done in,
which uses:
def _parse_optional(self, arg_string):
# if it doesn't start with a prefix, it was meant to be positional
if not arg_string[0] in self.prefix_chars:
return None
def _get_option_tuples(self, option_string):
also uses the parser's own prefix_chars.
During parsing (several layers down)
def consume_optional(start_index):
# if the action is a single-dash option and takes no
# arguments, try to parse more single-dash options out
# of the tail of the option string
chars = self.prefix_chars
if arg_count == 0 and option_string[1] not in chars:
Here, the parser's own prefix_chars is used to handle the chained short-dash
options.
---
In sum, while Argument_Group can have its own prefix_chars, that is only used
for help formatting. It's the parser's prefix_chars that is used when parsing.
The group's chars is ignored.
The _ArgumentGroup__init__ suggests something more than simple inheritance may
have been intended for prefix_chars, but in practice all it affects is the
help.
I haven't seen this issue raised before, and since this group parameter is not
documented, I think it's safe to ignore it.
An alternative is to have add_argument_group (or _ArgumentGroup__init__)
explicitly reject the prefix_chars parameter.
--
___
Python tracker
<https://bugs.python.org/issue45656>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45673] argparse error with option with optional value
paul j3 added the comment: https://bugs.python.org/issue9338 argparse optionals with nargs='?', '*' or '+' can't be followed by positionals As you can see this is an old issue, but still too big for a quick fix. As a general rule, don't use `nargs` like this where there's ambiguity as to how many values will be allocated to the argument. -- ___ Python tracker <https://bugs.python.org/issue45673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45673] argparse error with option with optional value
paul j3 added the comment: Put the required positional first $ myapp myfile -s or one of the store_true arguments $ myapp -s -j myfile I think $ myapp -s -- myfile will work as well, but that needs to be tested. The '-s' has to be followed by something won't be confused for an argument, such as nothing, or a flag. -- ___ Python tracker <https://bugs.python.org/issue45673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38736] argparse: wrong type from get_default when type is set
paul j3 added the comment: Yes you can set the default to be any object, such as an evaluated string. If it isn't a string it won't be passed through 'type'. The purpose of the delayed evaluation that I described is to avoid unnecessary evaluations. The worse case would be a write filetype. You don't want to create (or over write) a default file if it never gets used. (I intend to close this issue). -- ___ Python tracker <https://bugs.python.org/issue38736> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38736] argparse: wrong type from get_default when type is set
Change by paul j3 : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38736> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38821] argparse calls ngettext with deprecated non-integer value
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue38821> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38843] Document argparse behaviour when custom namespace object already has the field set
paul j3 added the comment:
It doesn't have to be a special class. It can be a `argparse.Namespace` object.
If the preexisting namespace has an attribute set, the action default will not
over write it.
In [85]: parser = argparse.ArgumentParser()
...: parser.add_argument('--foo', default='bar')
...: parser.parse_args([],
namespace=argparse.Namespace(foo=123, baz=132))
Out[85]: Namespace(baz=132, foo=123)
This is described in comments at the start of parse_known_args()
# add any action defaults that aren't present
for action in self._actions:
if action.dest is not SUPPRESS:
if not hasattr(namespace, action.dest):
if action.default is not SUPPRESS:
setattr(namespace, action.dest, action.default)
# add any parser defaults that aren't present
for dest in self._defaults:
if not hasattr(namespace, dest):
setattr(namespace, dest, self._defaults[dest])
There are many details about 'defaults' that are not documented. This might
not be the most significant omission.
I have not seen many questions about the use of a preexisting namespace object
(here or on StackOverflow). While such a namespace can be used to set custom
defaults (as shown here), I think it is more useful when using a custom
Namespace class, one the defines special behavior.
Originally the main parser's namespace was passed to subparsers. But a change
in 2014, gave the subparser a fresh namespace, and then copied values from it
back to the main namespace. While that gave more power to the subparser's
defaults, users lost some ability to use their own namespace class.
https://bugs.python.org/issue27859 - argparse - subparsers does not retain
namespace
https://bugs.python.org/issue9351 - argparse set_defaults on subcommands should
override top level set_defaults
https://bugs.python.org/issue34827 - Make argparse.NameSpace iterable (closed)
--
___
Python tracker
<https://bugs.python.org/issue38843>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38950] argparse uses "optional arguments" for "keyword arguments"
paul j3 added the comment: This related to an old issue https://bugs.python.org/issue9694 argparse required arguments displayed under "optional arguments" argparse defines two initial argument groups, titled 'positional arguments' and 'optional arguments'. Alternatives have been suggested, such as 'flagged arguments' and/or 'required arguments'. But nothing was settled. Users can define their own argument groups. I'd suggest closing this a duplicate, though we can certainly revisit the earlier discussion. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue38950> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39076] Use types.SimpleNamespace for argparse.Namespace
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue39076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39058] argparse should preserve argument ordering in Namespace
paul j3 added the comment: This patch changes the super class, _AttributeHolder. ArgumentParser and Actions also inherit from this, though they have their own _get_kwargs methods, and so aren't affected by the sort and its removal. I just had occasion on stackoverflow to discuss the order in which attributes are added. A poster wanted to preserve the sys.argv order. https://stackoverflow.com/questions/58904423/find-the-order-of-arguments-in-argparse-python3/58905067#58905067 Most attributes are added as defaults at the start of parsing - via a loop through parser._actions. Predefining the namespace, SUPPRESS defaults, parser.set_defaults may alter this default order. Anyways removing the sort makes sense, and the proposed change phrase "in the order attributes were added" is sufficiently general. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue39058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39167] argparse boolean type bug
paul j3 added the comment:
Despite the name, the 'type' parameter specifies a function, not a Python
class.
The only string that produces False is the empty one: bool(''). So 'type=bool'
is valid Python, even if it isn't useful.
With `nargs='+'` there's no problem with providing strings like 'False',
'true', 'no', 'oui', 'niet', but if you want to convert those to boolean
True/False values, you need to write your own 'type' function.
There was a recent bug/issue that proposed providing such a function (or
importing it from another module), and shadowing the existing 'bool' function,
but that has been rejected (I think). It isn't really needed, and the proposed
solution was too language specific.
Seems to me that expecting your user to provide an open ended list of 'True
False False True' strings would be rather confusing, or at least require a
complicated 'help' string. In any case it's not a common enough case to
require any changes to the core argparse functionality.
In sum, it isn't clear what the bug is, or what patch you expect. This sounds
more like a StackOverflow question, than a bug report.
--
___
Python tracker
<https://bugs.python.org/issue39167>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39167] argparse boolean type bug
paul j3 added the comment: The rejected boolean type proposal: https://bugs.python.org/issue37564 -- ___ Python tracker <https://bugs.python.org/issue39167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError
paul j3 added the comment: This is a complicated issue that needs a lot of thought and testing before we make any changes. While all Actions have the 'required' attribute, the programmer can only set it for optionals. _get_positional_kwargs() will raise an error if the programmer tries to set it for a positional. For a positional its value is determined by the nargs value. The distinction between positionals and optionals occurs through out argparse, so we shouldn't put much effort (if any) into making their handling more uniform. (The fundamental distinction between the two is whether the action.option_strings list is empty or not.) A fundamental difference in parsing is that an optional's Action is called only if the flag is used. A positional's Action is always called. _parse_known_args starts with a list of positionals positionals = self._get_positional_actions() The nested consume_positionals function removes actions from this list. Earlier versions raised an error at the end of parsing if this list was not empty. In the current version that's been replace by the 'required_actions' test (which tests both positionals and optionals). It was this change over that resulted in the bug/feature that subparsers (a positionals Action) are no longer required (by default). Positionals with nargs='?' and '*' pose an extra challenge. They are, in a sense, no longer 'required'. But they will always be 'seen' because their nargs is satisfied by an empty list of values. But that would overwrite any 'default' in the Namespace. So there's the added step in _get_values of (re)inserting the action.default. And it's the handling of that 'default' that gives rise to the current issue. These two positionals can also be used in a mutually_exclusive_group. To handle that 'take_action' has to maintain both the 'seen_actions' set and the 'seen_non_default_actions' set. -- ___ Python tracker <https://bugs.python.org/issue36078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39283] Add ability to inherit unittest arguement parser
paul j3 added the comment: The issue of testing a script that uses argparse has come up on StackOverFlow a number of times. As noted the unittesting framework(s) often use their own parsers (not necessarily argparse). That means they are looking at the sys.argv commandline. It is difficult then to provide arguments that apply both to the framework, and your own script. If you try to your own options, the unittest parser will complain about unrecognized arguments. As a first step, your parser should only run when used as a script, not when imported (by the unittester). In other words, only call `parse_args` in the 'if __name__' block. If you do need to do unittesting of your parser, there are several monkey-patching options: use 'parser.parse_args(argv)' calls, where 'argv' can be None if used as script, and a custom list when being tested. Some will modify the sys.argv during testing. The test_argparse.py unittest file tests both ways. testing parser output may also require patching. Help and errors are sent to sys.stdout or sys.stderr. test_argparse.py uses an ArgumentParser subclass that redefines the error() and exit() methods, and redirects stdout/err. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue39283> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39197] argparse: title and description for mutually exclusive arg groups
paul j3 added the comment:
A mutually_exclusive_group is not an argument_group. It affects parsing and
the usage, but does nothing in the help lines.
A mutually_exclusive_group may be nested in an argument_group if you want
another group title.
g1 = parser.add_argument_group('My Required Group')
g2 = g1.add_mutually_exclusive_group()
Groups are not really designed for nesting, but this is one case the nesting
works and is useful. Nesting, to the extent it works, is simple a consequence
of inheritance from the _Argument_Container class.
Changing the title of the default action group is always an option,
mutually_exclusive or not. Other bug/issues have suggest changing that title
at creation time, or giving the user a choice (maybe even defining 3 default
groups). But for now we recommend creating your own argument group(s) if you
don't like the titles of the default one(s).
So no, I don't think anything should be changed simply because a
mutually_exclusive group is marked as required.
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue39197>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39173] _AttributeHolder of argparse should support the sort function or not?
paul j3 added the comment: I don't think the SO question is relevant. It's about changing the order of Actions in the Help and/or usage. Here it's a question of whether to sort the `argparse.Namespace` display. I think it's been adequately discussed in the recent bug/issues such as 39058. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue39173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39197] argparse: title and description for mutually exclusive arg groups
paul j3 added the comment: https://bugs.python.org/issue9694 is the original issue about the titles of the base argument groups. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39809] argparse: add max_text_width parameter to ArgumentParser
paul j3 added the comment: https://bugs.python.org/issue13041 is (I think) the latest issue/patch to deal with the help width. I don't like the idea of adding more parameters to the `ArgumentParser` class. It's too complicated already. There are a couple of ways that a user can do this already. One is a custom version of the `parser.format_help`, though as your patch shows, that actually has to go through the `_get_formatter` method. Only `format_help` is listed in the public API. Another is a subclass of HelpFormatter. It just needs to customize the `width` parameter. I vaguely recall suggesting such a subclass in a previous bug/issue, but can't find that. Subclassing HelpFormatter is an established way of customizing the format. Here's a discussion of this on StackOverflow. It uses a simple lambda as `formatter_class`: https://stackoverflow.com/questions/44333577/explain-lambda-argparse-helpformatterprog-width formatter = lambda prog: argparse.HelpFormatter(prog, width=100) and https://stackoverflow.com/questions/3215/max-help-position-is-not-works-in-python-argparse-library -- ___ Python tracker <https://bugs.python.org/issue39809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39809] argparse: add max_text_width parameter to ArgumentParser
paul j3 added the comment: But you can replace the simple 'lambda' with a function that takes the max with 'columns'. In other words, include: width = _shutil.get_terminal_size().columns width -= 2 width = min(max_text_width, width) The only thing that the 'formatter_class' parameter requires is a callable that takes 'prog' as argument. That can be a class, a subclass, a lambda or a function. -- ___ Python tracker <https://bugs.python.org/issue39809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39845] Argparse on Python 3.7.1 (Windows) appends double quotes to string if it ends with backward slash
paul j3 added the comment: Could you show the sys.argv (for both the linux and windows cases)? print(args) (without your correction) might also help, just to see the 'raw' Namespace. (I'd have to restart my computer to explore the Windows behavior myself). -- ___ Python tracker <https://bugs.python.org/issue39845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39845] Argparse on Python 3.7.1 (Windows) appends double quotes to string if it ends with backward slash
paul j3 added the comment: Then this isn't an argparse issue. Probably not even a Python one. The windows shell (which one? cmd.exe? power? some batch) is making the substitution. I see lots of discussion about Windows use of backslash, both as directory separator and escape. None seems to exactly apply. For your application the use of a custom 'type' function might well be appropriate, but it's not something we want to add to argparse. It's a user specific patch. -- ___ Python tracker <https://bugs.python.org/issue39845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39955] argparse print_help breaks when help is blank space
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue39955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError
paul j3 added the comment: You are right, this part of the same issue. _get_value() tests '==SUPPRESS==' both for type and choices. -- ___ Python tracker <https://bugs.python.org/issue36078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19462] Add remove_argument() method to argparse.ArgumentParser
paul j3 added the comment: I think it can be closed. -- ___ Python tracker <https://bugs.python.org/issue19462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40303] argparse parse_args args parameter bug or intended
paul j3 added the comment:
'type=bool' doesn't get any special treatment. 'bool' is a builtin Python
function.
test with
def mybool(astr):
print("mybool:", astr, len(astr), bool(astr))
return bool(astr)
The trick to getting a False value is to pass a genuinely empty string.
As can be seen in several previous bug/issues, 'bool' is allowed as a type
function, but since the only string that returns False is the empty one, it
isn't very useful. And we've resisted attempts give it some special treatment.
Users can write their own 'type' function that accepts language specific
'true/false' words. Otherwise we encourage the use of 'store_true',
'store_false' action values.
--
___
Python tracker
<https://bugs.python.org/issue40303>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40365] argparse: action "extend" with 1 parameter splits strings into characters
paul j3 added the comment:
This is a consequence of Python's own definition of append vs extend
In [730]: alist = []
In [731]: alist.append('astring')
In [732]: alist
Out[732]: ['astring']
In [733]: alist.extend('astring')
In [734]: alist
Out[734]: ['astring', 'a', 's', 't', 'r', 'i', 'n', 'g']
In [735]: alist.extend(['astring'])
In [736]: alist
Out[736]: ['astring', 'a', 's', 't', 'r', 'i', 'n', 'g', 'astring']
Normally 'add_argument' doesn't check for valid parameters, but some Action
subclasses do their own checking,
'extend' inherits the nargs==0 test from 'append'. (extend just modifies the
__call__, not the __init__ method.
But I wonder, was this situation discussed in the original bug/issue?
--
___
Python tracker
<https://bugs.python.org/issue40365>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40420] argparse choices formatter
paul j3 added the comment: The display of the choices has been discussed in previous issues. When the choices is long there isn't a clean way of handling the display. I'd suggest using a 'metavar' to show a short value, and then enumerate the choices in the help text. Use the 'Raw' help formatter to handle newlines as desired. Choices get displayed in 3 places - the usage, the help, and error messages. Metavar replaces 2 of those. An alternative to choices is a custom 'type' function. An example would be all integers between 0 and 100. Choices would work, but make a poor display regardless of formatting. -- ___ Python tracker <https://bugs.python.org/issue40420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40509] In argparse, allow REMAINDER(...) arguments in a mutually exclusive group
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue40509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40509] In argparse, allow REMAINDER(...) arguments in a mutually exclusive group
paul j3 added the comment: Handling the positional with '?' and '*' in a mutually_exclusive_group is tricky enough! I believe your user can use the '--' to get the same effect. -- ___ Python tracker <https://bugs.python.org/issue40509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40420] argparse choices formatter
paul j3 added the comment: Related topic re. long usage with choices : https://bugs.python.org/issue16418 -- ___ Python tracker <https://bugs.python.org/issue40420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40509] In argparse, allow REMAINDER(...) arguments in a mutually exclusive group
paul j3 added the comment:
A flagged argument with REMAINDER works just fine in a mutually exclusive group.
group.add_argument('-g', nargs='...')
positionals in such a group can only have ? or *. If you check the code, and
past issues you'll see that those require some special handling. Normally that
kind of positional is always 'seen', because an empty list (not strings)
satisfies those nargs. One positional can work in a mutually exclusive group
because it's been made to work, not because the fit is natural.
Search past issues for REMAINDER to check whether your concerns have been
raised before. If I recall correctly, even without a group, handling a
flagged argument with REMAINDER is more robust than a positional.
--
___
Python tracker
<https://bugs.python.org/issue40509>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42501] Improve error messages for argparse choices using enum
paul j3 added the comment: choices is fine for a few strings, but quickly becomes awkward with other types and large numbers. The testing isn't an issue, since it just does a simple `in/contains` test. But display, whether in usage, help or error, is problematic if you try anything too fancy. metavar gets around some of those issues, but doesn't change the error messages. Custom type or action is the best alternative. I'm in favor omitting the enums mention in the docs, since it seems to be more confusing than helpful. -- ___ Python tracker <https://bugs.python.org/issue42501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42547] argparse: add_argument(... nargs='+', metavar=) does not work with positional arguments
paul j3 added the comment: Duplicate of https://bugs.python.org/issue14074 argparse allows nargs>1 for positional arguments but doesn't allow metavar to be a tuple -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42547] argparse: add_argument(... nargs='+', metavar=) does not work with positional arguments
paul j3 added the comment: I'll reopen it - your patch, while not a complete resolution, does take care of the immediate error. -- resolution: duplicate -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue42547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42572] Better path handling with argparse
paul j3 added the comment: What exactly do you do with a path argument? Admittedly I'm not expert with os and os.path modules, but isn't a path just a string passed to a function such as cwd(), or joined to another create a filename. I don't know what a 'path' type or action would do. -- ___ Python tracker <https://bugs.python.org/issue42572> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42572] Better path handling with argparse
paul j3 added the comment:
The pathlib.Path is new since I paid much attention to os matters (I cut my
teeth on py2.5).
Off hand it looks like the user could
import pathlib
parser.add_argument('-p', type=pathlib.Path)
to convert a string into a Path object.
A custom type function could call this, and apply any desired methods before
returning the Path object. But that should be up to the user, not the
`argparse` developers.
Importing path specific modules such as pathlib (which in turn has a lot of
imports) goes against the attempt to reduce the number of unnecessary imports
with modules like argparse.
https://bugs.python.org/issue30152
Reduce the number of imports for argparse
After this diet argparse still imports os, and uses:
os.path.basename
I might also note that argparse has only one custom 'type' function, the
FileType factory. Other common type functions like 'int' and 'float' are
Python builtin's. Adding a custom 'bool' (to be used instead of the builtin
'bool') has been rejected.
https://bugs.python.org/issue37564
json, yaml, and datetime types have also been rejected
https://bugs.python.org/issue35005
--
___
Python tracker
<https://bugs.python.org/issue42572>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
