paul j3 added the comment:
There's a bug in the HelpFormatter.add_argument method. It does not take into
account the extra indentation of subactions (sub parsers) when calculating
self._action_max_length.
The corrected method and a test case is in the attached file.
class MyFormatter
paul j3 added the comment:
A fix that I am exploring would wrap the Action instantiation call in
add_argument with a try/except block
That is replace:
def add_argument(...)
action = action_class(**kwargs)
...
with
try:
action
paul j3 added the comment:
I realized while answering a Stackoverflow question that the resolve method has
the pieces for removing an Action from the parser. It removes an existing
Action so that the new, conflicting one, can replace it.
It's meant to be used with flagged arguments
paul j3 added the comment:
Here's a EnumType factory class, modeled on FileType.
class EnumType(object):
"""Factory for creating enum object types
"""
def __init__(self, enumclass):
self.enums = enumclass
def __call__(self, astring):
paul j3 added the comment:
I'm not quite sure what you mean by 'the enum type to be stored directly'.
With my type function, the string input is converted to an enum object and that
is stored in the Namespace. You can't be any more direct than that.
Or are you thinking that `argparse` has
paul j3 added the comment:
Here's a type function that enumerates the enum in the error message:
def enumtype(astring):
try:
return CustomEnumType[astring.upper()]
except KeyError:
msg = ', '.join([t.name.lower() for t in CustomEnumType])
msg = 'CustomEnumType
paul j3 added the comment:
The `type` parameter is a *function* that takes a string, and returns a valid
value. If it can't convert the string it is supposed to raise an error. The
default one is a do-nothing identity (take a string, return the string). `int`
is the Python function
paul j3 added the comment:
This assertion error caused by brackets (and other 'odd' characters) in the
metavar is a known issue.
http://bugs.python.org/issue11874
http://bugs.python.org/issue14046
The formatter that handles line wrapping of the usage line is fragile.
--
nosy
paul j3 added the comment:
`get_default` and `set_defaults` are parser methods, and do more than set or
get a particular Action attribute. 'Set' for example changes both the
'parser._defaults' attribute, and a 'action.default' attribute. Defaults are
complex and can be defined in at least 3
paul j3 added the comment:
`parser.set_defaults` lets you set a default for any `dest`. It does not have
to be connected with an argument. See what the docs say about using it to set
an action linked to a subparser.
`arg1 = parser.add_argument(...)` returns an `Action` object. The parser
paul j3 added the comment:
A related issue which Sworddragon found just before starting this issue is
http://bugs.python.org/issue9625
The handling of defaults in argparse is a bit complicated. In general it errs
on the side of giving the user/developer freedom to set them how ever
paul j3 added the comment:
Right, the only arguments that a `store_true` Action class accepts are:
option_strings, dest, default=False,required=False, help=None
parser.add_argument() massages its parameters a bit, and then uses the 'action'
parameter to construct an Action subclass
paul j3 added the comment:
Also, argparse.PARSER is '+...'
'? * +' have closely matched analogs in regex patterns. '...' and '+...' do
not. So Python users will have an intuitive idea of what nargs='*' means.
nargs='...' is not so obvious.
As a general rule, the document does not expose
paul j3 added the comment:
argparse.FileType serves 2 purposes
- handling filenames for simple quick shell-like scripts
- as a model for custom 'types', specifically one that uses a class to generate
the desired type callable.
Other bug-issues show that it hasn't aged well. It doesn't work
paul j3 added the comment:
These two types of groups serve different purposes and aren't designed to nest
or interact.
An argument group groups arguments in the help lines. It does not affect
parsing at all. It can't be used to add a 'group' of arguments to another
group.
A mutually
paul j3 added the comment:
To wrap this up, the correct way to specify that 2 or more positionals share a
'dest' is to supply that dest as the first parameter. If the help should have
something else, use the `metavar`.
import argparse
parser = argparse.ArgumentParser
paul j3 added the comment:
You can give the positional any custom name (the first parameter). You just
can't reuse it (by giving 2 positionals the same name). And if you don't like
what the 'help' shows, you can set the 'metavar'. That way only you see the
positional's name.
The name
paul j3 added the comment:
(Important correction at the end of this post)
The test that you are complaining about occurs at the start of the
'add_argument' method:
def add_argument(self, *args, **kwargs):
add_argument(dest, ..., name=value, ...)
add_argument
paul j3 added the comment:
What are you trying to accomplish in the examples with a 'dest'? For a
positional, 'dest' is derived from the 'foo' name. There is no need to supply
'dest', in fact produces the error you get. It has nothing to with this action
type (as your last example
paul j3 added the comment:
None of the `append` actions makes sense with positionals. The name (and hence
the 'dest') must be unique. And positionals can't be repeated.
There are other ways to put a pair of values in the Namespace. For example,
after parsing
args.x = [42, 43
paul j3 added the comment:
An alternative would be to wrap a non-identifier name in 'repr()':
def repr1(self):
def fmt_name(name):
if name.isidentifier():
return name
else:
return repr(name)
type_name = type(self
paul j3 added the comment:
http://bugs.python.org/issue15125
argparse: positional arguments containing - in name not handled well
Discussion on whether positionals 'dest' should translate '-' to '_'.
--
___
Python tracker rep...@bugs.python.org
http
paul j3 added the comment:
Yes, the '_' makes it accessible as an attribute name. But the presence of '-'
in the option name has a UNIX history. That is a flag like '--a-b-c' is
typical, '--a_b_c' is not.
There is less of precedent for a flag like '@@a@b' or '--a@b'.
Here's the relevant
paul j3 added the comment:
The code that converts '-' to '_' is independent of the code that uses
'prefix_chars'.
The '-' conversion handles a long standing UNIX practice of allowing that
character in the middle of option flags. It's an attempt to turn such flags
into valid variable names
paul j3 added the comment:
And the corresponding bug issue
http://bugs.python.org/issue9351
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24251
paul j3 added the comment:
Another example of this patch causing backward compatibility problems
http://bugs.python.org/issue24251
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9351
paul j3 added the comment:
I mentioned in the related bug/issue that no one has to use odd characters and
spaces in the Namespace. While they are allowed by 'getattr' etc, the
programmer has the option of supplying rational names in the 'dest' parameter.
There's also the question of what
paul j3 added the comment:
Off hand I don't see a problem with this patch (but I haven't tested it yet).
But I have a couple of cautions:
The docs say, regarding the Namespace class:
This class is deliberately simple, just an object subclass with a readable
string representation
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 alternatively consumes optionals
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
'nargs
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 rep
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
___
Python
paul j3 added the comment:
A similar Stackoverflow question
http://stackoverflow.com/questions/21692395/hiding-selected-subcommands-using-argparse/21712058#21712058
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22848
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 constructing a test
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 review how
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',
description
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()
I'd be hesitant to add
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://stackoverflow.com
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:
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 brackets
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23058
___
___
Python-bugs-list mailing list
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:
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 rep...@bugs.python.org
Changes by paul j3 ajipa...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22500
___
___
Python-bugs-list
Changes by paul j3 ajipa...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23555
___
___
Python-bugs-list
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
paul j3 added the comment:
closed with reference to #9334
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22672
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 __call__
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, **kwargs):
# adds 'parser_class
Changes by paul j3 ajipa...@gmail.com:
--
assignee: - docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23487
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 appended
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 than your
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
that time. Conceivably
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:
Related issues are:
http://bugs.python.org/issue13824 - argparse.FileType opens a file and never
closes it
http://bugs.python.org/issue14156 - argparse.FileType for '-' doesn't work for
a mode of 'rb'
As discussed earlier FileType was meant as a convenience
paul j3 added the comment:
This an issue for parse_args as well. parse_args just calls parse_known_args,
and raises an error if extras is not empty.
Early on in parsing, it tries to classify argument strings as either optionals
(--flags) or positionals (arguments). And there's an explicit
paul j3 added the comment:
Duplicate of
http://bugs.python.org/issue22433
--
resolution: - duplicate
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22909
paul j3 added the comment:
A notational point - you are adding a subparser, not an argument, to the
subparsers action.
Why would a user want to use `help=argparse.SUPPRESS`, as opposed to simply
omitting the `help` parameter? The effect would be the same as your patch.
Another
paul j3 added the comment:
The patch with a major rewrite of '_format_actions_usage' handles this usage
problem correctly:
usage: try_para_in_meta.py [-h] input_file(s) [input_file(s) ...]
The error is the result of usage group formatter trying to remove excess `()`.
To give an idea
paul j3 added the comment:
I'm exploring modifying that patch by adding a 'subnamespace' attribute to the
subparsers Action object. This would give the user, or the main parser control
over the namespace that is passed to a subparser.
For example:
subnamespace = getattr(self
paul j3 added the comment:
Patch tests are added to an existing 'Lib/test/test_argparse.py' file. I use
existing test cases as a pattern any new tests.
-
Your test file runs fine with the patch I proposed for Issue 9334.
-
The argparse code uses
paul j3 added the comment:
A possible problem with this patch is that it overrides any Namespace given by
the user. In the test example:
parser.parse_args(['X'], namespace=argparse.Namespace(foo=3))
the result is 'foo=2', the setdefault from the subparser. Previously, and with
a single
paul j3 added the comment:
This issue has already been raise in
http://bugs.python.org/issue9334
argparse does not accept options taking arguments beginning with dash
(regression from optparse)
There I proposed leaving '_negative_number_matcher' unchanged, but only use it
to set
paul j3 added the comment:
In the attached patch I modified 'add_parser' to take a 'parser' keyword
parameter. If given, it is used as the parser, rather than create a new one.
Thus an existing parser, or one created with a custom ArgumentParser class,
could be used as a subparser
paul j3 added the comment:
A simpler solution is to make a copy of each Action when importing a parent
parser. The current practice is to just copy references. With a copy, an
Action will belong to only one group and parser, and the 'resolve' handler will
operate without problems
paul j3 added the comment:
If the empty argument group has a 'description' it is displayed. For example
with positionals group that I mentioned earlier:
parser = argparse.ArgumentParser()
parser._action_groups[0].description = 'test'
parser.print_help()
produces
usage
Changes by paul j3 ajipa...@gmail.com:
Added file: http://bugs.python.org/file36728/sample3.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22401
Changes by paul j3 ajipa...@gmail.com:
Removed file: http://bugs.python.org/file36656/sample3.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22401
paul j3 added the comment:
A 'store_true' action takes 0 arguments. In effect `nargs=0`.
With an `optional` (flagged) argument, the default `False` is used if the flag
is absent, and set to `True` when the flag is encountered (its Action
`__call__` function is run).
A `positional
paul j3 added the comment:
I've added a patch with tests that I think handles this case, without messing
with existing test cases. It adds a new 'space' test right before the existing
one, one that explicitly handles an '=' arg_string.
If the space is in the 1st part, it is marked
paul j3 added the comment:
Proposed patches like this are supposed to be generated against the current
development version (3.5...), especially if they are 'enhancements' (as opposed
to bugs). But there isn't much of a difference in argparse between 2.7+ and
3.4+ (except one nested yield
paul j3 added the comment:
Your patch fails:
python3 -m unittest test_argparse.TestEmptyAndSpaceContainingArguments
specifically these 2 subcases:
(['-a badger'], NS(x='-a badger', y=None)),
(['-y', '-a badger'], NS(x=None, y='-a badger')),
At issue
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +bethard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22401
___
___
Python-bugs-list mailing list
Changes by paul j3 ajipa...@gmail.com:
Added file: http://bugs.python.org/file36674/example.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22433
Changes by paul j3 ajipa...@gmail.com:
Removed file: http://bugs.python.org/file36672/example.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22433
Changes by paul j3 ajipa...@gmail.com:
Added file: http://bugs.python.org/file36656/sample3.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22401
Changes by paul j3 ajipa...@gmail.com:
Removed file: http://bugs.python.org/file36648/sample3.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22401
Changes by paul j3 ajipa...@gmail.com:
Added file: http://bugs.python.org/file36648/sample3.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22401
Changes by paul j3 ajipa...@gmail.com:
Removed file: http://bugs.python.org/file36635/sample3.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22401
paul j3 added the comment:
'sample3.py' contains a '_handle_conflict_parent' function.
With the help of a change in '_add_container_actions' it determines whether a
conflicting action occurs in multiple parsers (and argument_groups). If it
does, it deletes it from the correct group, without
New submission from paul j3:
When there's a conflict involving an argument that was added via 'parents', and
the conflict handler is 'resolve', the action in the parent parser may be
damaged, rendering that parent unsuitable for further use.
In this example, 2 parents have the same '--config
paul j3 added the comment:
One way to reduce the testing burden, and to be extra safe regarding backward
compatibility is to make this action optional, rather than the default.
For example, make `_prog_name` importable (i.e. change the name), and then
expect the user to use it explicitly
paul j3 added the comment:
This assertion has triggered several bug issues, either due to an empty group
like this, or certain characters in the metavars.
http://bugs.python.org/issue17890
'argparse: mutually exclusive groups full of suppressed args can cause
AssertionErrors'
http
paul j3 added the comment:
When I apply `prog3.diff` to my 3.5.0dev, and run
python3 -m unittest Lib/test/test_argparse.py
I get 2 failures, both over 'usage: python3 -m [unit]test'.
It also fails with
python3 test_argparse.py
I suspect it would also fail if I ran the tests
paul j3 added the comment:
In argparse.py, I would put a utility function like `_prog_name` near the start
in the 'Utility functions and classes' block.
In test_argparse.py, I don't see the purpose of the `progname` changes in the
TestParentParsers class. That class wasn't producing
paul j3 added the comment:
Attached is a patch for 3.5.0 dev that adds UsageGroups. Now different 'kinds'
are implemented as subclasses, which are accessed via the registry:
_XorUsageGroup - replicate action of MutuallyExclusiveGroups
_AndUsageGroup - an inclusive group
paul j3 added the comment:
http://bugs.python.org/issue14191
'argparse doesn't allow optionals within positionals'
implements a 'parse_intermixed_args()' method, which parses all of the
optionals with one pass, followed by a second pass that handles the
positionals. It does
paul j3 added the comment:
http://stackoverflow.com/questions/25626109/python-argparse-conditionally-required-arguments
asks about implementing a 'conditionally-required-arguments' case in
`argparse`. The post-parsing test is simple enough:
if args.argument and (args.a is None or args.b
paul j3 added the comment:
The patch tests assume the test is being run in a particular way:
python -m unittest ...
But I often use
python3 -m unittest ...
or
python3 test_argparse.py
both of which fail these tests.
Testing this change might be more difficult than implementing
paul j3 added the comment:
What if the package is run without `-m`?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22240
___
___
Python-bugs
paul j3 added the comment:
I ran into a (possibly) related compiling problem (for 'default', 3.5 branch)
in `asdl.py`:
class Module(AST):
def __init__(self, name, dfns):
...
self.types = {type.name: type.value for type in dfns}
The dictionary comprehension
paul j3 added the comment:
Package might be the wrong term. How about a directory with a `__main__.py`
file, and no local imports (relative or not)? In my tests it runs with and
without the -m.
--
___
Python tracker rep...@bugs.python.org
http
paul j3 added the comment:
Maybe the problem is with the latest documentation build, not your patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13540
paul j3 added the comment:
You need line continuation characters '\'
.. class:: Action(option_strings, dest, nargs=None, const=None, default=None, \
type=None, choices=None, required=False, help=None, \
metavar=None
paul j3 added the comment:
While we are talking the Action class, the documentation isn't clear that the
'add_argument' method returns an Action object, specifically one the
subclasses. More than once, when answering Stackoverflow questions I've
recommended assigning this object
paul j3 added the comment:
It still needs a documentation patch.
And if the documentation was clearer, would sfllaw's patch still be needed?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15125
paul j3 added the comment:
The formatting of the descriptor line for this class is not consistent with the
classes for this module.
It lacks 'class'.
It is all bold
In contrast
class argparse.ArgumentParser(prog=None, ...
uses bold for only the name
paul j3 added the comment:
I had noticed the `global _log_to_stderr` in `util.log_to_stderr()`, but hadn't
taken time to track down where it is used.
Not only is it passed from the 'util' module to the 'forking' one, but it is
also passed via a piped pickle from parent to child process
paul j3 added the comment:
I added a print line to a 'windows' example from the documentation:
from multiprocessing import Process
print 'importing multiprocessing'
def foo():
print 'hello'
p = Process(target=foo)
p.start()
Run with Python 2.7.0 on linux I get
paul j3 added the comment:
For documentation, ['this','is','a','test'] might be a bit clearer than 'this
is a test'.split(). But generating a list of strings by split is, I think, a
pretty basic idiom.
But for testing purposes the split() version is a bit more robust because it is
closer
401 - 500 of 773 matches
Mail list logo
