paul j3 added the comment:
What you are asking about is the fact that different arguments can share a
'dest'.
https://docs.python.org/3/library/argparse.html#dest
The 'append_const' action has an example of shared 'dest'. It says:
The 'append_con
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue18769>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
Under what circumstances would this be useful?
http://bugs.python.org/issue19462 asks for a 'remove_argument' method. That
seems to be most useful if the argument is inherited from a parent parser.
A subparsers argument could be inherited from a paren
paul j3 added the comment:
There's a partial overlap with this issue
http://bugs.python.org/issue22848
which seeks to hide a subparser - both in the help lines and the choices lists.
--
___
Python tracker
<http://bugs.python.org/is
paul j3 added the comment:
The short `repr` is produced in Python2.7, but not 3.5.
Your test case:
action = argparse._StoreAction(['--file], dest='file_path')
error = argparse.ArgumentError(action, 'File not found.')
print(str(error))
print(repr(err
paul j3 added the comment:
This formatter produces an error if one or more of the arguments uses the
default `None` type (a string). This is because `None` does not have a
`.__name__`.
This HelpFormatter probably has been rarely, if ever, used. The metavar
parameter works just as well
paul j3 added the comment:
The choice of 'type' for this parameter is occasionally confusing, because the
connection to the Python 'type()' function or what we think of as 'native
types' is only tangential.
A name like 'converter' or 'string_co
paul j3 added the comment:
In
_ActionsContainer._add_container_actions there is this note:
# add container's mutually exclusive groups
# NOTE: if add_mutually_exclusive_group ever gains title= and
# description= then this code will need to be expanded as above
In other bug/i
paul j3 added the comment:
I've attached a file that monkey patches the
_ActionsContainer._add_container_actions method.
It corrects the `_container` attribute of the copied mutually exclusive groups.
I've only tested it for the case presented in this issue (and the relate
Sta
paul j3 added the comment:
Argument groups are not designed to be nested.
If you print_help the parent parser, you'll see that the sub_args are missing
entirely, not just displaced. They appear in the usage, but not the help
lines. sub_group has no record that it was added to global_
paul j3 added the comment:
There are 2 issues
parsing - how to reserve one or more arguments for use by following
'positionals'. Fixes have been proposed in other bug/issues, but aren't
trivial.
usage formatting - the stock formatter displays all optionals first, f
paul j3 added the comment:
I can understand changing
'7'.split()
but this change is IMO ugly:
- >>> print(parser.parse_args('--foo B cmd --arg1 XX ZZ'.split()))
+ >>> print(parser.parse_args(['--foo', 'B', 'cmd'
paul j3 added the comment:
How about:
These store the values True and False respectively (and default to False
and True if absent).
The reference to `store_const` is confusing, since almost no one uses that
action.
The `store_const` paragraph has:
(Note that the const keyword
New submission from paul j3:
The documentation for Mutual exclusion
https://docs.python.org/3/library/argparse.html#mutual-exclusion
needs a note that a mutually exclusive group may contain one positional
argument. But that argument must be either nargs='?', or nargs='*
paul j3 added the comment:
This has been raised before. I think
http://bugs.python.org/issue9253
is the correct issue.
It used to be that 'subparsers' were required. But there was a change in how
'required' arguments were tested, and 'subparsers' fell throug
paul j3 added the comment:
The usage line formatter needs a major rewrite.
Currently it formats usage for all the arguments as one line (two actually,
optionals and positionals are handled separately), and then breaks it into
'wrappable parts'. It then compiles the lines from t
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue26394>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
I need to study that patch more, but I don't like the fact that it operates at
the core of the parsing (e.g. in 'take_action'). That's a dangerous place to
add features. Unexpected behaviors and backwards compatibility problems are
too likely.
paul j3 added the comment:
Let's see if I understand the proposed patch
Each call to 'take_action' is replaced with a save to a 'action_with_values'
dictionary
For a flagged (optional) it saves the 'args' and 'option_string'; for
positionals
paul j3 added the comment:
http://stackoverflow.com/a/35144270/901925
dynamically-set-default-value-from-cfg-file-through-argparse-python
is my answer to a similar recent (Feb 2015) SO question.
I rather like the idea of using collections.ChainMap on the dictionary versions
of the namespace
paul j3 added the comment:
Yes, the use of ordered dictionary would be right. Your code would still
reorder actions that have fallback values, but that wouldn't affect others.
Yes, a fallback hook at the end of parsing would have to be placed before the
'required' testing, not
paul j3 added the comment:
This ArgumentDefaultHelpFormatter issue should probably be raised in its own
issue. It applies to 'required' optionals, but any patch would be independent
of the issues discussed here.
This class defines a method that adds the '%(default)' s
paul j3 added the comment:
By text and location the sidebar does not apply specifically to this example.
It applies to the whole page, 'This page contains the API reference
information.'
Documentation for argparse is indeed a problem - both because of its complexity
and how
paul j3 added the comment:
Is this the kind of scenario that you have problems with?
parser = argparse.ArgumentParser()
sp = parser.add_subparsers(dest='cmd')
p1 = sp.add_parser('cmd1')
p1.add_argument('-f')
p2 = sp.add_parser('cmd2&
paul j3 added the comment:
I can see changing the group title from 'optional arguments' to 'options' or
'optionals'
parser._optionals.title
'optional arguments'
But I don't think there's a need to change references in the code or it
paul j3 added the comment:
Neither 'parents' or 'resolve' are documented in any detail. Most of what I
know comes from reading the code.
'parents' are, I think, most useful when importing a parser from some other
module. It lets you add arguments to your own p
paul j3 added the comment:
I made a mistake of trying to add to or refine a closed patch. Maybe I need to
move the dbldash.patch over here for more formal consideration.
--
___
Python tracker
<http://bugs.python.org/issue14
paul j3 added the comment:
The best way to get an idea added is to write a good complete patch. 2nd best
is to provide constructive input on ideas that are already here. 3rd is to
illustrate how you would hope to use such a feature. Include ideas on how the
usage/help/error display would
paul j3 added the comment:
desbma:
Rereading your latest code and comment:
> * The meaning of the 'type' parameter for StoreEnumAction is somewhat
> different than for other actions (enum class vs callable that validates)
it occurred to me that that parameter does not have t
paul j3 added the comment:
I just found a case where `dest` is `SUPPRESS` - the default subparsers setup.
_SubParsersAction(option_strings=[], dest='==SUPPRESS==', nargs='A...',
...
If I make this Action 'required' (in the current distribution 'subpar
Changes by paul j3 :
--
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issue26967>
___
___
Python-bugs-list mailing list
Unsubscrib
paul j3 added the comment:
It's been 2 years since I worked on this patch. In the issue discussion
http://bugs.python.org/issue14910 there was no mention of short v long options.
The unit tests only look at longs.
The result is that with the abbrev off, it disables all use of com
paul j3 added the comment:
Argument Groups are not designed for nesting, and despite their names and
subclassing, Mutually exclusive groups and Argument Groups are not meant to be
used together (with one exception).
I agree that the error is obscure, but it occurs in a particularly fragile
paul j3 added the comment:
Someone needs to take the current argparse.py, set the default value of this
parameter to False, and run the unittest file. This should turn up this case,
and possibly others that fail when abbreviations are turned off. Then we have
to debate whether such failures
paul j3 added the comment:
I answered a similar question recently on Stackoverflow when the user wanted to
use `type=hex`.
http://stackoverflow.com/questions/37006387/python-argparse-hex-error
In another recent bug/issue the poster want a `enum` type. It's not hard to
define a functio
paul j3 added the comment:
So far I've proposed adding a 'hook' at the end of '_parse_known_args', that
would give the user access to the 'seen_non_default_actions' variable. This
function could perform an almost arbitrarily complex set of logical
co-occurr
paul j3 added the comment:
The attached file subclasses ArgumentParser, explores how these optparse
methods might be added to argparse. The __name__ section demonstrates how they
might be used.
argparse differs from optparse in a number of ways:
- all actions are included in the parser
paul j3 added the comment:
It certainly looks like a documentation issue. `action` doesn't make sense
here. `add_subparsers` normally creates an Action of type `_SubParsersAction`.
'action' for normal 'add_argument' command defines the Action type created at
paul j3 added the comment:
My opinion is that this is an unnecessary addition.
Reasons:
- it is easy to add as a custom action class
- I haven't seen other requests for it
- the append retains information about the argument strings that extend looses
- it is easy flatten the app
paul j3 added the comment:
http://bugs.python.org/issue11588 is an earlier request for 'necessarily
inclusive' groups.
The patches that I proposed there are more general, allowing for other logical
combinations of arguments, as well as nesting groups. As such it is more
complex
paul j3 added the comment:
OK, so you are thinking about what happens to the subparsers `dest` when the
user names a command. That isn't handled by the `store` action, but by the
call of the subparsers action
class _SubParsersAction(Action):
def __c
Changes by paul j3 :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issue23487>
___
_
paul j3 added the comment:
As to the nature of the error when 'add_subparsers' is given an 'action'
parameter:
'add_subparsers' does several things to 'kwargs' before it passes them to the
relevant Action class.
def add_subparsers(self,
paul j3 added the comment:
I can't reproduce this with either 3.4.2 or the latest development
'argparse.py' file (that I just downloaded).
There have been some issues with the method used format the usage line,
_format_actions_usage. It formats the line with all the group brac
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue23058>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
Without actually running this case I think it is caused by the
http://bugs.python.org/issue9351 patch.
You can check the __call__ method for class _SubParsersAction and how it
handles invocation of the subparser. Does it get the existing namespace, or a
new one
paul j3 added the comment:
This is another manifestation of the
http://bugs.python.org/issue9351 partial patch (on how the namespace of the
parser relates to the namespace of the subparser).
see also
http://bugs.python.org/issue23058
--
___
Python
Changes by paul j3 :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue23555>
___
___
Python-bugs-list mailing list
Unsubscrib
paul j3 added the comment:
http://bugs.python.org/issue22672
float arguments in scientific notation not supported by argparse
is a newer complaint about the same issue. I've closed it with link to here.
--
___
Python tracker
paul j3 added the comment:
closed with reference to #9334
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22672>
___
___
Python-
Changes by paul j3 :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22500>
___
___
Python-bugs-list mailing list
Unsubscrib
paul j3 added the comment:
The handling of defaults is a bit complicated.
Note that `set_defaults` both sets a `_defaults` attribute, and any actions
with a matching `dest`. So it could change the `default` of 0, 1 or more
actions.
def set_defaults(self, **kwargs):
self
paul j3 added the comment:
It's a possible addition, but I don't have sense of the demand for it.
I wonder, what does the class offer that a function like this doesn't?
def adate(date_string):
return datetime.datetime.strptime(date_string,'%Y-%m-%d').date(
paul j3 added the comment:
Examples of datetime types from Stackoverflow:
http://stackoverflow.com/questions/21437258/defining-python-argparse-arguments
The suggested answer (but not accepted) is 'type=lambda s:
datetime.datetime.strptime(s, '%Y-%m-%d')'
another
http
paul j3 added the comment:
It'll take me a while to work through this proposed patch. My first reaction
is that I am uncomfortable with adding an attribute to all parsers just to
implement this help feature. For one thing it seems to cross functionality
boundaries.
I need to revie
paul j3 added the comment:
Giving the `subparsers` Action a `metavar` might achieve everything the
proposed patch does - without any code changes.
In the 1st test case:
subparsers = parser.add_subparsers(title='subcommands',
d
paul j3 added the comment:
This overlaps with http://bugs.python.org/issue22240
argparse support for "python -m module" in help
This issue also tries to handle zip files as well.
Deducing the `prog` was moved to a separate function.
One challenge with that issue was construct
paul j3 added the comment:
A similar Stackoverflow question
http://stackoverflow.com/questions/21692395/hiding-selected-subcommands-using-argparse/21712058#21712058
--
___
Python tracker
<http://bugs.python.org/issue22
paul j3 added the comment:
It's the spaces and/or brackets in the metavar, along with a usage line that is
long enough to wrap, that is raising this error.
It's a known problem.
http://bugs.python.org/issue11874
--
nosy: +paul.j3
paul j3 added the comment:
I wouldn't describe this as bug, just a nuance on how parsers and subparsers
play together.
To the main parser, the subparser argument looks like another positional. It
allocates strings to it and any following positionals based on their respective
'na
paul j3 added the comment:
And the behavior does match the help
{ls,du} ... vm [vm ...]
It's just that one of the strings is allocated to the first `...`, whereas you
expected it to be put in the second.
--
___
Python tracker
paul j3 added the comment:
Look at http://bugs.python.org/issue9338
argparse optionals with nargs='?', '*' or '+' can't be followed by positionals
That has a proposed patch that wraps the main argument consumption loop in
another loop.
The current loop a
paul j3 added the comment:
http://bugs.python.org/issue21633
also deals with the formatter of subparsers. I note there that few of
parameters of the main parser propagate to the subparsers.
The current design gives the programmer maximum control, at the expense of a
bit of typing. If I
paul j3 added the comment:
Another example where the old way would have worked better
http://bugs.python.org/issue27859
--
___
Python tracker
<http://bugs.python.org/issue9
paul j3 added the comment:
This call used to be
namespace, arg_strings = parser.parse_known_args(arg_strings, namespace)
But in 2014 (2.7.9) http://bugs.python.org/issue9351 was implemented
As noted in the title and comment in the code, the idea was to give more power
to the defaults set
paul j3 added the comment:
I've posted a file that runs your code as you expect.
It uses a custom Action class (like your test case). It subclasses
._SubParsersAction, and replaces the 9351 namespace use with the original one.
I use the registry to change the class
paul j3 added the comment:
In http://bugs.python.org/issue27859 I've demonstrated how a subclass of
_SubParsersAction can be used to revert the behavior to pre 2.7.9, passing the
main namespace to the subparser.
The only other change is to the parser registry:
parser.register(&#
Changes by paul j3 :
--
Removed message: http://bugs.python.org/msg274336
___
Python tracker
<http://bugs.python.org/issue9351>
___
___
Python-bugs-list mailin
paul j3 added the comment:
Clint, 'nargs=argparser.REMAINDER' ('...') may do what you want
p=argparse.ArgumentParser()
p.add_argument('--subscipt_args', nargs='...')
p.add_argument('pos',nargs='*')
p.parse_
paul j3 added the comment:
Clint, the problem is the argparse uses different argument allocation method
than optparse.
optparse gives the '--subscipt_args` Action all of the remaining strings, and
says - 'consume what you want, and return the rest'. So you consume up to (and
paul j3 added the comment:
The display of the Action help lines is determined by the parser.format_help
function
https://docs.python.org/3/library/argparse.html#printing-help
This function creates a Formatter, and then loads it with a 'stack' of
sections. Sections are display
paul j3 added the comment:
Yes there was/is a bug that made subparsers optional.
http://bugs.python.org/issue9253
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue28
paul j3 added the comment:
It may help to know something about how defaults are handled - in general.
`add_argument` and `set_defaults` set the `default` attribute of the Action
(the object created by `add_argument` to hold all of its information). The
default `default` is `None`.
At the
paul j3 added the comment:
One thing that this default behavior does is allow us to append values to any
object, just so long as it has the `append` method. The default does not have
to be a standard list.
For example, in another bug/issue someone asked for an `extend` action. I
could
paul j3 added the comment:
The current error message is the result of http://bugs.python.org/issue10424
and http://bugs.python.org/issue12776
Before the test was just:
if positionals:
self.error(_('too few arguments'))
The 2nd patch reworked the test to include the revise
paul j3 added the comment:
Try `nargs='?'` or try providing a `default` along with the '*'.
Including your ARGUMENT action in the error message is intentional.
The test for this error message is:
required_actions = []
for action in self._actions:
paul j3 added the comment:
Simply including a `default` parameter, even with the default default None,
changes the error message
In [395]: parser=argparse.ArgumentParser()
In [396]: parser.add_argument('cmd');
In [397]: a=parser.add_argument('args',na
paul j3 added the comment:
My suggestion to use `metavar=('A','')` to streamline the usage creates
problems with the help code
http://bugs.python.org/issue14074
The tuple metavar does not work right for positionals. That's a old issue that
should have been fixed l
701 - 778 of 778 matches
Mail list logo
