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
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue46228>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by paul j3 :
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue46080>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 -&g
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
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
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
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
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue46101>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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
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
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
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 f
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
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
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
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
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45504>
___
___
Python-bugs-list
Change by paul j3 :
--
stage: resolved -> test needed
status: closed -> pending
___
Python tracker
<https://bugs.python.org/issue45235>
___
___
Python-bugs-
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 a
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"
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
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
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue45235>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.
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
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
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 ab
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue45587>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<ht
Change by paul j3 :
--
Removed message: https://bugs.python.org/msg401554
___
Python tracker
<https://bugs.python.org/issue41255>
___
___
Python-bugs-list mailin
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
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
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 tha
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
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
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue44587>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue44986>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 n
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.
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
gener
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
paul j3 added the comment:
You test with RawDescriptionHelpFormatter, but quote from the
RawTextHelpFormatter.
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue43
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
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
q
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
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, p
paul j3 added the comment:
I've added a script that does what you want, but with a simple utility function
instead of a parent (or lots of copy-n-paste).
I explored the code a bit, and have an idea that might correct the [parent]
behavior.
In the method that copies a parent's groups
paul j3 added the comment:
The parents mechanism is not elaborate. It copies groups and actions by
reference. The comments that I quoted actually come from that method that does
this copying.
>From a quick glance at that code I see that it does not preserve the group
>n
paul j3 added the comment:
The mutually exclusive arguments are displayed with in the argument group, at
least in my testing. From a copy-n-paste of your example:
In [8]: parser.print_help()
usage: ipython3 [-h]
[--from-args FROM_ARGS | --from-files FROM_FILES | --from-stdin
paul j3 added the comment:
It's not clear what your patch does that the existing 'store_const' doesn't.
Even 'append_const' does the same except for a extra level of list/tuple
nesting.
But I'll admit that I didn't much need for 'extend' addition, but others,
including the original
paul j3 added the comment:
Sometimes patches have unforeseen benefits. My earlier patch for this issue,
parse_intermixed_args, has been useful beyond the OP's case.
https://stackoverflow.com/questions/50916124/allow-positional-command-line-arguments-with-nargs-to-be-seperated-by-a-flag
paul j3 added the comment:
So in the big picture, the purpose of this change is to treat the inputs like a
kind of state-machine.
In the bigger example, the `**` positional values are processed one by one,
using the interspersed optionals to set state parameters.
`args.sources` then ends
paul j3 added the comment:
I haven't had a chance to study your longer posts, but it seems to me that the
AddFruitAction example could just as well be implemented with
parser.add_argument('--color', nargs='*', action='append')
with post parsing processing to create the 'fruits' dicts
paul j3 added the comment:
Years ago I proposed a `format_wrapper`, a Format class factory
https://bugs.python.org/issue12806#msg218395
also
https://bugs.python.org/issue39809
There I show that the formatter may be lambda
formatter = lambda prog: argparse.HelpFormatter(prog, width=100
paul j3 added the comment:
This issue is discussed in:
https://bugs.python.org/issue34724
argparse subparser help indent too short
and
https://stackoverflow.com/questions/3215/max-help-position-is-not-works-in-python-argparse-library
paul j3 added the comment:
I was thinking of a refactoring that included the ', '.join(...) loop, but on
further thought your refactoring might be enough for the case I raised.
For example:
def _format_option_with_args(self, option_string, args_string):
if option_string.startswith
paul j3 added the comment:
The refactoring looks reasonable.
But while we are tweaking:
def _format_action_invocation(self, action):
I wonder if we also give users more control over how multiple option strings
are formatted. Currently if
parser.add_argument('-f', '--foo', help
paul j3 added the comment:
Your patch is incomplete, without documentation or tests.
Your example is incomplete. That is _CustomAction? What namespace does your
patch produce.
It's been a while since I worked on the intermixed patch, but as I recall the
OP was happy with the fix. Also I
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
paul j3 added the comment:
I'd have to study the code (and docs), but I'm not sure setting the `dest` to
'SUPPRESS' does anything meaningful.
default=argparse.SUPPRESS
is useful, keeping the default out of the namespace. That argument appears
only if the user has used the option
paul j3 added the comment:
I'm closing the is as a duplicate of https://bugs.python.org/issue23487, which
is already closed.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bug
paul j3 added the comment:
https://docs.python.org/3/library/argparse.html#customizing-file-parsing
in the docs describes how to customize the @file reading. This particular
extension handles several strings on a line, but that's not the limit of what
you could do.
You can also read
paul j3 added the comment:
An existing parser can be included in a new subparser via the 'parents'
mechanism. With that the _actions and groups of the parent are copied (by
reference) to the new subparser.
There are some rough edges to the parents mechanism, but people have used it to
add
paul j3 added the comment:
In the subparser example, it's the `build` subparser that puts '--overwritte'
in the unrecognized list. That is then passed back to the main parser, which
then issues the 'unrecognized' error, along with its own usage.
The subparser is called
paul j3 added the comment:
One caution - the type parameter is a callable (function) that takes one string
as argument. I proposed `pathlib.Path` because it does that, returning a Path
object. It's a class instance creator. I believe the module has other class
initiators.
bool() has
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
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
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/i
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
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
paul j3 added the comment:
We could look into using a different more compact 'prog' for these error
messages.
Currently the subparser 'prog' uses the main prog plus positionals plus the
subparser name. The goal is to construct a subparser usage that reflects
required input
paul j3 added the comment:
It's the subparser that's producing this error, specifically its 'prog'
attribute.
If I use a custom usage with a simple parser:
1129:~/mypy$ python3 issue42297.py --foo=on
usage: issue42297.py
one
two
three
issue42297.py: error: argument
paul j3 added the comment:
Provide a minimal reproducible example. I can't reproduce that run on error
message.
Also test with arguments like '--all-logs on', which issues an 'unrecognizeable
argument' error (with a different error reporting path).
Stripping excess newlines is normal
paul j3 added the comment:
Do you realize that `choices` can be a dictionary? And since you want the user
to supply a key, not a value, you might not want to use a type that does the
conversion.
To illustrate consider two ways of using a simple dictionary.
import argparse
adict
paul j3 added the comment:
In the Help formatting,
choice_strs = [str(choice) for choice in action.choices]
The use of `repr` in this check_value() error message was, I think, deliberate.
For simple choices like strings and numbers it doesn't matter. But for other
cases, it may help
paul j3 added the comment:
argparse : allow_abbrev behavior between 3.7 and 3.8
https://bugs.python.org/issue41534
covers this issue well enough. That latest change to `allow_abbrev` was
prompted by:
argparse: allow_abbrev=False stops -vv from working
https://bugs.python.org/issue26967
paul j3 added the comment:
A more recent issue shows that the use of a '*' positional in a
multually_exclusive_group is poorly understood and documented.
https://bugs.python.org/issue41854
That's part of why I am not enthusiastic about extending this to include
REMAINDER
paul j3 added the comment:
Give the positional a non-none default:
e.g.
group.add_argument('args', metavar='ARGUMENT', nargs='*', default=[],
help='arguments to PROGRAM')
Since a '*' or '?' positional works with an empty list of arguments, it is
"always
paul j3 added the comment:
Some StackOverFlow answers cusomizing this help method:
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
paul j3 added the comment:
That method could be customized in a HelpFormatter subclass. There already are
several subclasses (documented), and writing your own is allowed, if not
actually encouraged.
https://docs.python.org/3/library/argparse.html#formatter-class
Adding an extra parameter
paul j3 added the comment:
I'm not following this request either, especially the colored part.
However, I can imagine adding a variable that gives the user full control over
the action-invocation. In:
argparse.HelpFormatter._format_action_invocation method.
Currently it accepts
paul j3 added the comment:
For ArgumentParser, prog is defined as:
prog - The name of the program (default: sys.argv[0])
The comment in the `add_subparsers` method is:
# prog defaults to the usage message of this parser, skipping
# optional arguments and with no "
paul j3 added the comment:
'store_true/false' are subclasses of 'store_const'. All have a 'nargs=0'
value. It's that value which explains their behavior. ('append_const' would
also fall in this category)
In [2]: parser = argparse.ArgumentParser()
In [3]: parser.add_argument('foo', action
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41684>
___
___
Python-bugs-list
paul j3 added the comment:
I'm going to close this. 3.8 works as expected/documented, provided we use the
normal double dash protocol for long options. Single dash is best reserved
for single character options, where chaining is allowed.
--
stage: -> resolved
status: o
paul j3 added the comment:
When there are potential conflicts between arguments set by the main parser and
those set by a subparser, I often recommend giving the sub ones different
"dest" parameters. Then you can reconcile the different values after parsing.
There's not
paul j3 added the comment:
I've noted this behavior before.
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
Due to a change 2012, the subparser
paul j3 added the comment:
In your first example:
In [29]: parser = argparse39.ArgumentParser(allow_abbrev=True)
In [30]: parser.add_argument('-o');
In [32]: parser.parse_known_args(['-o','test
paul j3 added the comment:
I'd say the problem is with the deployment tool. Inputs like that should be
split regardless of who's doing the commandline parsing. With normal shell
input, quotes are used to prevent splitting, or to otherwise prevent
substitutions and special character
paul j3 added the comment:
This is the result of how default values are handled with '?' (and '*') nargs.
At the start of nested `take_action` function (which handles all actions) is
this code:
argument_values = self._get_values(action, argument_strings)
# error
paul j3 added the comment:
I just realized if the subparser argument used
default=argparse.SUPPRESS
it would not clobber values (default or user) set by the main parser.
(a 'store_true' would have to be replaced with a 'store_const' to do
paul j3 added the comment:
The docs could change
"catch errors manually"
to
"catch ArgumentError manually"
But while 'argparse.ArgumentError' is imported, it is not documented. We have
to study the code to learn when it is raised.
Its class def:
def __i
paul j3 added the comment:
For custom handling of unrecognized arguments, use parser_known_args(). You
don't need this new parameter.
--
___
Python tracker
<https://bugs.python.org/issue41
paul j3 added the comment:
I didn't pay attention to the patch that added this "exit_on_error" parameter.
So I don't know exactly what error handling it was supposed to handle or why.
But given the location of the code change, it does not handle every possible
error.
Specifi
1 - 100 of 773 matches
Mail list logo
