Change by paul j3 :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34046>
___
Change by paul j3 :
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34188>
___
Change by paul j3 :
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by paul j3 :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue34458>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by paul j3 :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue34479>
___
___
Python-bugs-list mailing list
Unsubscrib
paul j3 added the comment:
I'm closing this since the https://bugs.python.org/issue11874 fix also handles
this issue.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
paul j3 added the comment:
In your proposed change:
params = dict(vars(action), prog=self._prog)
+ if action.option_strings:
+ params['flag'] = action.option_strings[0]
'params', as I noted earlier already includes the 'dest' and 'option_strings'
list
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34479>
___
___
Python-bugs-list
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34458>
___
___
Python-bugs-list
paul j3 added the comment:
While I don't think this change will cause any backward compatibility issues, I
wonder whether it does much good.
https://docs.python.org/3/library/argparse.html#exiting-methods
already documents the option of customizing `parser.exit` and `parser.error
paul j3 added the comment:
In your example, what is 'flag'? There's no Action attribute of that name.
There is a 'dest' and a 'option_strings' list.
All the 'help' '%(...)s' does is display one of the Action object attributes,
the most common one is 'default'.
Try
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue34742>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
Looks like I had my say on this in the Stackoverflow link (3 yrs ago).
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue34
paul j3 added the comment:
The PR 4396 should be closed.
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue32027>
___
___
Python-bugs-list m
paul j3 added the comment:
It's been sometime since I looked at this issue.
The main sticking point is passing unittests, and ensuring that there are no
backward compatibility issues.
But, since FileType is a standalone class, anyone could put a corrected version
in their own workspace
paul j3 added the comment:
Errors that are associated with a specific argument, such as a wrong 'type' do
get usage from the appropriate subparser.
e.g.
In [164]: p.parse_args('--foo 1 cmd1 --bar x'.split())
usage: ipython3 cmd1 [-h] [--bar BAR]
ipython3 cmd1: error: argument --bar
paul j3 added the comment:
The subparser is called with `parse_known_args` which just puts unknown args in
a _UNRECOGNIZED_ARGS_ATTR attribute slot in the namespace, which is then passed
back to the main parser.
(this occurs in _SubParsersAction.__call__)
If `parser.parse_known_args
paul j3 added the comment:
I agree that a custom Action subclass like this is the way to go.
The regular 'append' is implemented in _AppendAction class, which is different
from the default _StoreAction. So even if there was enough demand for this new
idea to be put into development
paul j3 added the comment:
The 'choices' mechanism is quite simple. As noted for testing it simply uses
an 'in' test.
For help formating it uses
choice_strs = [str(choice) for choice in action.choices]
result = '{%s}' % ','.join(choice_strs)
In other words, it's treated
paul j3 added the comment:
Duplicate of
https://bugs.python.org/issue22909 [argparse] Using parse_known_args, unknown
arg with space in value is interpreted as first positional arg (closed as
duplicate)
https://bugs.python.org/issue22433 Argparse considers unknown optional
arguments
paul j3 added the comment:
Parsing is a two step process. First the strings are passed through
def _parse_optional(self, arg_string):
which classifies them as 'O', an optional flag, or 'A', an argument.
- no prefix char => A
- the string is in the dictionary of option_strings (e.g. '--l
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34299>
___
___
Python-bugs-list
paul j3 added the comment:
Updating you Python3.7 might change the behavior. If I read
https://github.com/python/cpython/commits/master/Lib/argparse.py
correctly, subparsers are no longer required by default (it reverted back to
earlier Py3 behavior). There is a proposed patch
paul j3 added the comment:
The 'choices' mechanism is a simple 'value in choices' test. A dictionary (or
other mapping) works because it works with 'in'.
'type' as noted is the means that argparse provides for transforming an input
string into some other object (most commonly a number
paul j3 added the comment:
Your code runs fine under 3.6.5.
But if I add 'subparsers.required=True', I get your error. It's having
problems formatting the name of the subparsers command when issuing the error
message.
If I add a 'dest' to the add_subparsers I get the expected error
paul j3 added the comment:
argparse does import 'textwrap', but as '_textwrap', so it could be used with:
argparse._textwrap.dedent(...)
Importing your own is cleaner.
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue34
paul j3 added the comment:
Do you understand why this is happening?
Subparsers is, in effect, a positional argument with 'choices' - the choices
being the parsers (and their aliases).
But '-dr' looks like an flagged (optionals) argument. Since you didn't define
such an argument, it gets
paul j3 added the comment:
`parse_intermixed_args` was added in v 3.7.
https://docs.python.org/3/library/argparse.html#intermixed-parsing
https://stackoverflow.com/questions/50916124/allow-positional-command-line-arguments-with-nargs-to-be-seperated-by-a-flag
Change by paul j3 <ajipa...@gmail.com>:
--
nosy: +paul.j3
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue15327>
___
__
paul j3 <ajipa...@gmail.com> added the comment:
I've attached a file that tries out the idea of building a custom `metavar` in
the `add_parser` method.
It subclasses argparse._SubParsersAction, and registers it with the parser. No
other modification to production code is re
paul j3 <ajipa...@gmail.com> added the comment:
Also
https://bugs.python.org/issue27303
[argparse] Unify options in help output
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
paul j3 <ajipa...@gmail.com> added the comment:
https://bugs.python.org/issue29626
Issue with spacing in argparse module while using help
This deals with a extra space that is produced when a blank metavar is used to
produce a more compact help line
-s , --service help text
My a
paul j3 <ajipa...@gmail.com> added the comment:
The usage formatter is brittle, especially the part that adds mutually
exclusive markings to the normal usage string. I don't think I've seen this
error before, but I'm not surprised.
A real fix requires a rewrite of the usage formatter,
paul j3 <ajipa...@gmail.com> added the comment:
This is normal behavior for argparse.
People have asked before for a more compact display. I remember suggesting
changes to the HelpFormatter subclass on Stackoverflow questions, and there's
probably one or more bug/issues addressing th
paul j3 <ajipa...@gmail.com> added the comment:
I've reviewed the comments and proposed patch, and still think that the custom
metavar is still the best fix.
subparses.metavar can be changed after subparsers has been created. The
programmer could, for example, write a simple helper fu
paul j3 <ajipa...@gmail.com> added the comment:
Since this feature is buggy, and there isn't an easy fix, we should probably
remove any mention of it from the docs. We can still leave it as an
undocumented legacy feature.
There is precedent for leaving `nargs` constants undocu
paul j3 <ajipa...@gmail.com> added the comment:
This subclass makes are one method change:
from:
def _get_help_string(self, action):
return action.help
to:
def _get_help_string(self, action):
help = action.help
if '%(default)' not in actio
paul j3 <ajipa...@gmail.com> added the comment:
This issue was raised in https://bugs.python.org/issue12713,
argparse: allow abbreviation of sub commands by users
A patch was implemented, and then reverted when it was found to be buggy.
Subcommands are not parsed the same as long o
paul j3 <ajipa...@gmail.com> added the comment:
>From the documentation, 16.4.4.1. Option value syntax
> For short options (options only one character long), the option and its value
> can be concatenated:
> Several short options can be joined together, using only
paul j3 <ajipa...@gmail.com> added the comment:
I haven't seen anyone try to use \n in a metavar before, but other special
characters like [] and () produce this assertion error. At this point the code
is trying split the usage into 2 or more lines, because it's too long for one.
It c
paul j3 <ajipa...@gmail.com> added the comment:
A REMAINDER that would work with a flag-like string would be too powerful, too
greedy.
In [64]: p = argparse.ArgumentParser();
In [65]: p.add_argument('--foo');
In [66]: p.add_argument('rest', nargs='...');
If the flag is firs
paul j3 <ajipa...@gmail.com> added the comment:
REMAINDER is not widely used, and probably was not tested thoroughly during
development. It works for the example given in the docs.
A variant, argparse.PARSER ('A...') is widely used. This is, effectively,
REMAINDER ('...') that re
paul j3 <ajipa...@gmail.com> added the comment:
Oops, I see I already mentioned 9334. Here the parsing sequence is a bit
different, and the fix I suggest there would not apply here. But the
underlying issue is still there - the parser has, in its first iteration,
determined that the
paul j3 <ajipa...@gmail.com> added the comment:
This is another expression of the bigger problem of handling arguments that
look like flags. In optparse the 'nargs' (or equivalent, it doesn't handle
positionals), control how many arguments an Option takes, regardless of their
paul j3 <ajipa...@gmail.com> added the comment:
Try adding a simple positional argument. '-ab' would still produce this error.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
paul j3 <ajipa...@gmail.com> added the comment:
This error message is intentional.
In def consume_optional(start_index):
# identify additional optionals in the same arg string
# (e.g. -xyz is the same as -x -y -z if no args are re
paul j3 <ajipa...@gmail.com> added the comment:
When I run your setup in ipython, I see a display of the newly added Action:
Out[2]: _StoreAction(option_strings=['--a-b', '--ab'], dest='a_b',
nargs=None, const=None, default=None, type=None, choices=None, help=None,
metava
paul j3 <ajipa...@gmail.com> added the comment:
Subparsers have aliases, argument option strings don't, at least not formally.
Once an argument is added, its flags are entered in several lists. One list
belongs to the Action itself, another belongs to the parser (it might ac
Change by paul j3 <ajipa...@gmail.com>:
--
nosy: +paul.j3
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32756>
___
__
Change by paul j3 <ajipa...@gmail.com>:
--
nosy: +paul.j3
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32833>
___
__
paul j3 <ajipa...@gmail.com> added the comment:
I attached a script that implements Evan's _match_argument idea, using a
ArgumentParser subclass. I think this is the safest way to add different
functionality to the parser. It (subclassing) is used, for example in pypi
extensions lik
paul j3 <ajipa...@gmail.com> added the comment:
To elaborate on my last comment, the existing subclasses that customize
formatting modify
_fill_text
_split_lines
_get_help_string
_get_default_metavar_for_optional
_get_default_metavar_for_positional
those are all 'private' m
paul j3 <ajipa...@gmail.com> added the comment:
In https://bugs.python.org/issue11354
'argparse: nargs could accept range of options count'
I explored the option allowing regex style range arguments, such as
nargs='{2,4}' or an equivalent tuple nargs=(2,4).
But that builds on
paul j3 <ajipa...@gmail.com> added the comment:
In the recently pushed, https://bugs.python.org/issue14191, "argparse doesn't
allow optionals within positionals"
we added new parsing functionality by defining a new parser method:
parse_intermixed_args
It added functionality w
paul j3 <ajipa...@gmail.com> added the comment:
That's not how flagged (optionals) arguments work.
The default value is used if the flag is not provided at all. One of your
arguments is a 'store_true'. Its default value if False, which is changed to
True if the '--device-get-capabi
paul j3 <ajipa...@gmail.com> added the comment:
A difficulty with writing a public API is that useful changes can occur at
almost any level of the class.
The existing subclasses modify small, but deep methods, ones that handle things
like line wrapping.
On the other hand, most of the
paul j3 <ajipa...@gmail.com> added the comment:
Did you copy the output right? Testing your parser:
Without any arguments, I get the exclusive group error - the group is required:
0930:~/mypy/argdev$ python3 issue18943.py
usage: issue18943.py [-h]
(--devi
paul j3 <ajipa...@gmail.com> added the comment:
In a recent stackoverflow question a user wanted this optional-subparsers
ability in Python 2.7.
https://stackoverflow.com/questions/46667843/how-to-set-a-default-subparser-using-argparse-module-with-python-2-7
Short of mod
paul j3 <ajipa...@gmail.com> added the comment:
I've changed your example a bit to clarify some points.
parser.add_argument('n', type=int)
group = parser.add_mutually_exclusive_group()
group.add_argument("-v", "--verbose", action="store_true")
paul j3 <ajipa...@gmail.com> added the comment:
As documented in many other issues, the usage formatter is brittle. It formats
the individual usages, joins them into a string. Then if too long to fit on one
line it tries t split into actions, etc. This split produces an assertion
paul j3 <ajipa...@gmail.com> added the comment:
And the actual exit is via `parse.error` and `parse.exit`, which are documented
in 16.4.5.9.
When run interactively in Ipython, exits (including the help) are captured and
displayed with:
In [896]: parser.parse_args()
usage: ipytho
Changes by paul j3 <ajipa...@gmail.com>:
--
nosy: +paul.j3
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30421>
___
__
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 looking
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 all
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 optparse parsing, a flagged option gets all
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:
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 string),
and `get_values` has special
Changes by paul j3 <ajipa...@gmail.com>:
--
nosy: +paul.j3
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31012>
___
__
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 <rep...@bugs.python.org>
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 only written
paul j3 added the comment:
http://bugs.python.org/issue27859
argparse - subparsers does not retain namespace
may complicate this issue. Due to changes in http://bugs.python.org/issue9351,
a user defined namespace is not passed to the subparsers. They get a fresh
namespace, which
paul j3 added the comment:
http://bugs.python.org/issue29670
argparse: does not respect required args pre-populated into namespace
wants to put 'required' values in the Namespace. That's a similar issue.
An idea that I tried for that (but didn't submit as a patch) is to move the
tests
paul j3 added the comment:
http://bugs.python.org/issue26394
Have argparse provide ability to require a fallback value be present
is a related issue - getting 'required' values from a config file.
--
___
Python tracker <rep...@bugs.python.org>
paul j3 added the comment:
I don't anticipate any backward compatibility issues with the proposed patch.
But at the same time it feels almost too trivial of an issue to merit a patch.
A short metavar such as `metavar="ID"' or even `metavar="_"' would be nearly as
comp
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
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 that can be applied
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 public or
not, not
Changes by paul j3 <ajipa...@gmail.com>:
--
nosy: +paul.j3
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30152>
___
__
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 <rep...@bugs.python.org>
<http://bugs.python.or
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 tracker
Changes by paul j3 <ajipa...@gmail.com>:
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
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
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
Changes by paul j3 <ajipa...@gmail.com>:
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by paul j3 <ajipa...@gmail.com>:
--
resolution: -> not a bug
stage: needs patch -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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:
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 proposal was to add
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 subparser
Changes by paul j3 <ajipa...@gmail.com>:
--
nosy: +paul.j3
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29715>
___
__
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 across
Changes by paul j3 <ajipa...@gmail.com>:
--
nosy: +paul.j3
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29777>
___
__
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_actions
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 respecting pre
Changes by paul j3 <ajipa...@gmail.com>:
--
status: closed -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29626>
___
__
paul j3 added the comment:
Sorry, I missed that. For some reason I looking something bigger.
That's coming from the `metavar=""'.
If I specify `metavar="xxx" that help line will have
-p xxx, --projectid xxx
Replace the 'xxx` with '', and you still have space betwee
paul j3 added the comment:
This help looks normal:
1427:~/mypy/argdev$ python3 issue29626.py delete -h
usage: cli delete [-h] [-p] userid
Deletes a user in your organization.
positional arguments:
userid The userid of user.
optional arguments:
-h, --help show
paul j3 added the comment:
With this setup
import argparse
parser=argparse.ArgumentParser(prog='cli')
parser.add_argument('nodes')
sp=parser.add_subparsers()
p1 = sp.add_parser('list', description='Lists nodes in your current project')
p1.add_argument('-p','--projectid', action='store_true')
p1
Changes by paul j3 <ajipa...@gmail.com>:
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
201 - 300 of 773 matches
Mail list logo
