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(
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
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
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 r
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:
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 u
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:
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. A
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', &#x
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.
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:
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:
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 proc
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:
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
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&#
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:
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:
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
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue40862>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue40615>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
The error is raised in ._get_values with this section:
# when nargs='*' on a positional, if there were no command-line
# args, use the default if it is anything other than None
elif (not arg_strings and action.nargs == ZERO_O
paul j3 added the comment:
It is an old unresolved issue (which resurfaced a few months ago)
https://bugs.python.org/issue9625
argparse: Problem with defaults for variable nargs when using choices
--
resolution: -> duplicate
___
Python trac
Change by paul j3 :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41047>
___
___
Python-bugs-
paul j3 added the comment:
No, parameters like `type` let the developer control what his users provides.
Violating that produces a runtime error, and exit.
But in general argparse does not try to control values that the developer uses.
There's plenty of time during development to
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue41136>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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/is
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:
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_co
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)
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
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([
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 subp
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 nothi
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
stat
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41684>
___
___
Python-bugs-list
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.ArgumentParse
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:
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 accept
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:
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:
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 work
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
REMAI
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:
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
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:
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
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
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
requir
paul j3 added the comment:
This is intended behavior of multi-nargs positionals. The 'one' string is
consumed by the 'file' argument, and there's no positional argument left to
consume the other strings.
The topic was raised and discussed previously
https://b
paul j3 added the comment:
I don't see an easy way around this. FileType is a class, and thus is a
callable. add_argument checks that the 'type' parameter is a callable (or a
string in the registry). Otherwise it gives the programmer a lot of freedom
regarding
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue37227>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
Mark,
Have you tried defining your own Argument Group? If that didn't work, what fix
do you want? Why?
--
___
Python tracker
<https://bugs.python.org/i
paul j3 added the comment:
There are earlier bug/issues about the '--'.
Also look at the parser code itself. Keep in mind that parsing is done in two
passes - once to identify flags versus arguments ('O/A') and then to allocate
strings to arguments. I don't
paul j3 added the comment:
I looked at this issue way back, in 2013:
https://bugs.python.org/issue13922
I probably shouldn't have tacked this on to a closed issue.
--
___
Python tracker
<https://bugs.python.org/is
paul j3 added the comment:
Xiang Zhang pointed out that the immediate error in this case was caused by the
empty mutually exclusive group:
https://bugs.python.org/issue26952#msg264835
The nesting fails because adding actions to the argument_group does not enroll
them in the mutually
paul j3 added the comment:
https://bugs.python.org/file29845/dbldash.patch
while written against an earlier version of `argparse`, does what you want. I
moved the '--' removal out of `_get_values` and into `consume_positionals`.
Note that a full patch should include test
paul j3 added the comment:
This is an old topic, though it may be easier to find a relevant StackOverflow
thread.
https://stackoverflow.com/a/19233287/901925 (a 2013 thread)
I and others have explained that the `type` parameter is supposed to be a
callable. The default Python `bool
paul j3 added the comment:
The use of `bool` as registry key only works because that object already exists
as a builtin. This amounts a form of shadowing, and sets a dangerous precedent.
type=bool
should work as documented at
https://docs.python.org/3/library/functions.html?highlight
paul j3 added the comment:
As discussed in https://bugs.python.org/issue23487, `action` works if the class
is compatible with argparse._SubParsersAction.
these commands all do the same thing:
parser.add_subparsers() # default
parser.add_subparsers(action='pa
paul j3 added the comment:
This patch lacks proper documentation, and is too English language specific.
For users who assume 'type' means a class rather than function (callable) this
change does not need documentation, since it accommodates that assumption. But
more experienced
paul j3 added the comment:
The problem described here is restricted to `?` and `*' positionals, and is
caused by the subtle way in which 'empty' optional positionals are handled.
The regular handling of defaults at the start of `parse_known_args` works fine.
The default is
paul j3 added the comment:
Another manifestation of the complications in handling '?' positionals is in
http://bugs.python.org/issue28734
argparse: successive parsing wipes out nargs=? values
--
___
Python tracker
<http://bu
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue31012>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
Another pre-existing namespace issue
http://bugs.python.org/issue28734
When positional nargs='?' or '*', the default (or []) overwrites the namespace
value. That's because the posiitonals are always 'seen' (by an empty str
paul j3 added the comment:
argparse roughly follows POSIX practice:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
Guideline 10:
The first -- argument that is not an option-argument should be
accepted as a delimiter indicating the end of options. Any
paul j3 added the comment:
The earlier issue for '--' as arguement
http://bugs.python.org/issue14364
With the patch I suggested there '-f--' and '--foo=--' work as arguments.
'--foo --' is still interpreted as a positionals switch.
In optpars
paul j3 added the comment:
I've seen this before, either in another bug/issue or a Stackoverflow question.
The basic change in RawTextHelpFormatter is to turn off the line wrapping for
texts like the description. Multiple newlines are preserved at this step.
But after assembling al
paul j3 added the comment:
http://bugs.python.org/issue17113
argparse.RawDescriptionHelpFormatter should not delete blank lines
This provides more details on why this is happening.
I suggest using adding a space between newlines, thus: '\n \n'.
HelpFormatter.format_help is just l
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue30421>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue35442>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
argparse.REMAINDER matches an empty list of arguments, just like '?' and '*'.
So they are always 'filled', even by `parse_args([])`.
'?' and '*' have some special handling of defaults in this case, see in
paul j3 added the comment:
Let me highlight something about
https://stackoverflow.com/a/15008806/169947
The original question was how to implement an Action that accepts 'True' or
'False' as an argument. Users often try `type=bool`, which doesn't work
because of t
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue35533>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
The proposed PR does not address this issue. It just adds comments to the
method code, which aren't really needed. The method is short and obvious. We
don't need, at this time, to get into questions of whether comments in
argparse.py conform to one o
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue36014>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
Defaults are handled into two stages.
At the start of parsing defaults are added to the Namespace.
At the end of parsing intact defaults are evaluated with 'type'.
But a nargs='?' positional gets special handling. It matches an empty stri
paul j3 added the comment:
By defining a custom 'type' function:
def foo(astr):
if astr is argparse.SUPPRESS:
raise KeyError
return astr
I get the full traceback
1831 def take_action(action, argument_strings, option_string=None
paul j3 added the comment:
What issue might have changed this behavior? I'm not aware of any that were
trying to change either the `seen_actions` and the 'required' tests, not any
dealing with pre-existing values in Namespace.
The current handling of defaults complicates
paul j3 added the comment:
One refactoring that I'd like to see is to move all the tests at the end of
_parse_know_known_args to its caller, parse_known_args. It would have to
return more values than the current namespace and extras, in particular the
see_actions and seen_non_default_ac
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue29777>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
allow_abbrev as added with http://bugs.python.org/issue14910
I contributed to the patch, but my memory isn't fresh. The fact that this
works across the subparser boundary is, in a sense, accidental. We didn't
think about how abbreviations are handled a
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue29715>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
I think that this string falls through to the last case in
'parser._parse_optional' (the first parsing loop)
# it was meant to be an optional but there is no such option
# in this parser (though it might be a valid option in a
paul j3 added the comment:
http://bugs.python.org/issue9334, 'argparse does not accept options taking
arguments beginning with dash (regression from optparse)'
is an old discussion about strings that begin with a dash and don't
match defined flags.
One propos
paul j3 added the comment:
The change to `_parse_optional` that did go through is the ability to turn off
abbreviations
http://bugs.python.org/issue14910
Even that has had a few complaints, http://bugs.python.org/issue29777
--
___
Python tracker
paul j3 added the comment:
How would you rank this issue relative to other `argparse` ones? Currently I'm
following 123 open issues.
--
___
Python tracker
<http://bugs.python.org/is
Changes by paul j3 :
--
resolution: -> not a bug
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by paul j3 :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24251>
___
paul j3 added the comment:
I'm going to close this. At most it calls for a documentation change. But
saying something like
It must be compatible with argparse._SubParsersAction.
will just confuse the average user. Any customization of this action class is
an advanced topic,
paul j3 added the comment:
And only for integers smaller than 257!
The problem is with this test in `take_action` function
# error if this argument is not allowed with other previously
# seen arguments, assuming that actions that use the default
# value
Changes by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue30163>
___
___
Python-bugs-list
paul j3 added the comment:
This issue was raised in 2013. The proposed patch is still pending
http://bugs.python.org/issue18943
I'm going to close this new one, though it is a good reminder of a rare, but
persistent bug.
--
___
Python tr
paul j3 added the comment:
This came up again, http://bugs.python.org/issue30163
An optional with int type and small integer default.
--
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issu
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue30152>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
In http://bugs.python.org/issue9353 Steven Bethard includes 'ArgumentTypeError'
in a list of values that "look like they should be public but aren't in
__all__::".
I take that `__all__` list to be the ultimate authority on what's pu
paul j3 added the comment:
I didn't mean to question the use of value tests in the 'type' callable. The
ArgumentTypeError example in the documentation does that kind of test.
Argparse is using the term 'type' loosely. It just means any kind of
conversion and/or test
paul j3 added the comment:
I haven't downloaded the development distribution to this computer, so can't
write formal patches at this time.
--
___
Python tracker
<http://bugs.python.o
paul j3 added the comment:
Any changes here including the latest pull request might conflict with
http://bugs.python.org/issue29553
Argparser does not display closing parentheses in nested mutex groups
If someone uses nested mutually exclusive groups (which I don't think they
should
101 - 200 of 778 matches
Mail list logo
