New submission from paul j3:
Argparse
15.4.5.1. Sub-commands
In the example:
parser.parse_args(['--help'])
usage: PROG [-h] [--foo] {a,b} ...
positional arguments:
{a,b} sub-command help
a a help
b b help
optional arguments:
-h, --help show this help message and exit
--foo
New submission from paul j3:
The production argparse applies the type conversion to a string default whether
it is needed or not. With the 12776 and 15906 patch, that conversion is
postponed, so that it is applied only once. However, for a positional argument
with nargs='*', that conversion
paul j3 added the comment:
If nargs=2, type=float, an argv like '1e4 -.002' works, but '1e4 -2e-3'
produces the same error as discussed here. The problem is that
_negative_number_matcher does not handle scientific notation. The proposed
generalize matcher, r'^-.+$', would solve
paul j3 added the comment:
We need to be careful about when or where _negative_number_match is changed.
We basically do:
parser = argparse.ArgumentParser(...)
parser._negative_number_matcher = re.compile(r'^-.+$')
This changes the value for the parser itself, but not for the groups
paul j3 added the comment:
While
parser._negative_number_matcher
is used during parser.parse_args() to check whether an argument string is a
'negative number' (and hence whether to classify it as A or O).
parser._optionals._negative_number_matcher
is used during parser.add_argument
paul j3 added the comment:
I think the `re.compile(r'^-.+$')` behavior could be better achieved by
inserting a simple test in `_parse_optional` before the
`_negative_number_matcher` test.
# behave more like optparse even if the argument looks like a option
paul j3 added the comment:
This patch makes two changes to argparse.py ArgumentParser._parse_optional()
- accept negative scientific and complex numbers
- add the args_default_to_positional parser option
_negative_number_matcher only matches integers and simple floats. This
is fine
New submission from paul j3 ajipa...@gmail.com:
The Windows programming guidelines for the multiprocessing module documentation
should include a warning that any logging initialization should be protected by
the 'if __name__' block. Otherwise you will get duplicate logging entries
paul j3 added the comment:
Since parse_args takes an optional Namespace argument, you can set the its
initial value to almost anything. For example, with the functions defined
previously:
parser = argparse.ArgumentParser()
parser.add_argument('-a','--algorithm', choices=['Q','S
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14074
___
___
Python-bugs-list mailing list
paul j3 added the comment:
My rewrite of _format_actions_usage in http://bugs.python.org/issue11874 should
take care of this issue. It keeps the groups and actions separate until the
final formatting step, bypassing the regular expression parsing.
--
nosy: +paul.j3
paul j3 added the comment:
This patch fixes the problem by joining the metavar terms with '|'. So the
help for the test case (adapted from an existing tuple test) looks like:
usage: PROG [-h] W1 [W2 ...] [X1 [X2 ...]] Y1 Y2 Y3 [Z1]
positional arguments:
W1|W2 w
X1|X2
paul j3 added the comment:
msg113512 - (view) Author: Steven Bethard (bethard)
Seems like there's minimally the bug that argparse should currently throw an
error if you add an argument after subparsers (since that argument will never
be parsed under the current semantics).
This isn't
paul j3 added the comment:
The test names are:
FAIL: test_failures_many_groups_listargs (__main__.TestFileTypeW)
FAIL: test_failures_many_groups_sysargs (__main__.TestFileTypeW)
FAIL: test_failures_no_groups_listargs (__main__.TestFileTypeW)
FAIL
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12806
___
___
Python-bugs-list mailing list
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13280
___
___
Python-bugs-list mailing list
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15428
___
___
Python-bugs-list mailing list
paul j3 added the comment:
It's everything I intend to add. Now I'm just waiting for a committer to act,
either with suggested changes, or a merge. I'm watching more than a dozen
argparse patches.
--
___
Python tracker rep...@bugs.python.org
http
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15112
___
___
Python-bugs-list mailing list
paul j3 added the comment:
Above in
http://bugs.python.org/issue14191#msg187051
I proposed a patch that is quite close to bethard's patch in
http://bugs.python.org/issue15112#msg166173
Both modify the same place, doing the same (pop items off arg_counts). The
logic is a little different
Changes by paul j3 ajipa...@gmail.com:
Added file: http://bugs.python.org/file29880/mixed.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14191
paul j3 added the comment:
I originally posted this on http://bugs.python.org/issue14191, but I think it
belongs here. The patch I proposed is similar to berthard's, popping items off
the end of 'args_counts'. I intend to check whether the logic is equivalent
Changes by paul j3 ajipa...@gmail.com:
Removed file: http://bugs.python.org/file29880/mixed.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14191
paul j3 added the comment:
These three changes end up testing for the same thing. The initial 'if' catches
different test cases. 'subparsers' or 'remainder' might 'confuse' the 'O'
test. The zero-width test ends up weeding out everything but the test cases
added for this issue.
# if we
paul j3 added the comment:
A possible further tweak is, in take_action(), test for conflicts before adding
the action to 'seen_non_default_actions'
if argument_values is not action.default:
#seen_non_default_actions.add(action)
for conflict_action
paul j3 added the comment:
The patch isn't a good unittest case because it produces an Error, not a
Failure. It does, though, raise a valid question about how a
Mutually_exclusive_group tests for the use of its arguments.
As you note, argparse does use the `is` test: `argument_values
paul j3 added the comment:
A further complication on this. With the arguments I defined in the previous
post
p.parse_args('--foo test --baz 257'.split())
gives the mutually exclusive error message. `sys.argv` does the same.
p.parse_args(['--foo', 'test', '--baz', '257'])
does
paul j3 added the comment:
Changing the test from
if argument_values is not action.default:
to
if argument_values is not action.default and \
(action.default is None or argument_values != action.default):
makes the behavior more consistent. Strings and large ints behave
paul j3 added the comment:
A possibly unintended consequence to this `seen_non_default_actions` testing is
that default values do not qualify as 'present' when testing for a required
mutually exclusive group.
p=argparse.ArgumentParser()
g=p.add_mutually_exclusive_group(required=True
paul j3 added the comment:
I should add that defaults with required arguments (or groups?) doesn't make
much sense. Still there's nothing in the code that prevents it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18943
paul j3 added the comment:
This `argument_values` comes from `_get_values()`. Most of the time is derived
from the `argument_strings`. But in a few cases it is set to `action.default`,
specifically when the action is an optional postional with an empty
`argument_strings
paul j3 added the comment:
At the very least the `is not action.default` needs to be changed. Else where
in argparse `is` is only used with `None` or constant like `SUPPRESS`. So
using it with a user defined parameter is definitely not a good idea.
Possible variations on how `is` behaves
paul j3 added the comment:
This patch uses a narrow criteria - if `_get_values()` sets the value to
`action.default`, then argument counts as 'not present'. I am setting a
`using_default` flag in `_get_values`, and return it for use by `take_action`.
In effect, the only change from previous
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11708
___
___
Python-bugs-list mailing list
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13824
___
___
Python-bugs-list mailing list
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14365
___
___
Python-bugs-list mailing list
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9694
___
___
Python-bugs-list mailing list
paul j3 added the comment:
Another situation in which this MultiGroupHelpFormatter helps is when one or
more of the groups includes an optional positional.
The regular formatter moves all the positionals to the end, after the
optionals. This move could easily break up a mutually exclusive
paul j3 added the comment:
On a related point, the 'action.required' value is set differently for '?' and
'*' positionals.
if kwargs.get('nargs') not in [OPTIONAL, ZERO_OR_MORE]:
kwargs['required'] = True
if kwargs.get('nargs') == ZERO_OR_MORE and 'default' not in kwargs
paul j3 added the comment:
This is a HelpFormatter function that takes a list of formatted actions, and
groups contiguous blocks of optional positional actions. It accounts for
optionals (via prefix_chars) and mutually exclusive groups.
Since it assumes 'parts' is a list, rather than string
paul j3 added the comment:
In this patch I implement a FileContext class. It differs from FileType
in 2 key areas:
- it returns a 'partial(open, filename, ...)'
- it wraps '-' (stdin/out) in a dummy context protecting the file from closure.
The resulting argument is meant to be used
paul j3 added the comment:
An alternative way to delay the file opening, is to return an instance that has
a `filename` attribute, and has an `open` method. This can be compactly added
to the `FileContext` that I defined in the previous patch. The `FileContext`
provides the `_ostest
paul j3 added the comment:
Steven's patch (subparse_optionals.diff) run with jakub's test case
(argparse_subparses_ambiguous_bug.py) works. But if the input string is
print(parser.parse_args('--foo baz'.split()))
produces
Namespace(cmd=None, foo='baz', foo1=None, foo2=None)
(I
paul j3 added the comment:
I think the correction to the problem that I noted in the previous post is to
return 'None, arg_string, None', rather than 'action, arg_string, None' in the
case where the action is found in a subparser.
This is what '_parse_optional' does at the end
paul j3 added the comment:
In the last patch, 'parser.scan = True' is needed to activate this fix. I left
that switch in for testing convenience.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14365
Changes by paul j3 ajipa...@gmail.com:
Removed file: http://bugs.python.org/file31888/subparser_patch.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14365
paul j3 added the comment:
This the argparse patch as described in the previous post, along with
test_argparse tests.
For now the tests handle both subparser required cases and not required ones (
http://bugs.python.org/issue9253 ). While error messages can differ based
paul j3 added the comment:
Looks like this behavior is intentional. This subclass adds a '%(default)s'
string to the help lines if:
if '%(default)' not in action.help:
if action.default is not SUPPRESS:
defaulting_nargs = [OPTIONAL, ZERO_OR_MORE
paul j3 added the comment:
parse_args() would see ['-foo', 'bar1,bar2,bar3', 'pos1', 'pos2']. The
splitting on space is done by the shell. So having your own code split
'bar1,bar2,bar3' is simplest. But that would be messed up if the user entered
'bar1, bar2, bar3...'. You could also ask
paul j3 added the comment:
When you add an argument, argparse creates an `Action`, and returns it. It
also places that action in various lists (e.g. parse._actions) and
dictionaries. A `remove_argument` function would have to trace and remove all
of those links. That's a non-trivial task
paul j3 added the comment:
Glenn
I looked at your t18a.py test case
parser = ArgumentParser()
parser.add_argument('--foo', dest='foo')
parser.add_argument('--bar', dest='bar')
parser.add_argument('foz')
parser.add_argument('baz', nargs='*')
and parse variations on 'a b c d
paul j3 added the comment:
The 'args=' parameter is the same as the first positional parameter used in
most of the examples. That is normal Python behavior.
15.4.4.5. Beyond sys.argv
explains this alternative way of specifying argv.
Still 2 bullet points could be added to 15.4.4.
- args
paul j3 added the comment:
This patch to argparse.rst adds the argument points to parse_args().
It also adds two points to the 'Upgrading optparse code' section, one about
using 'nargs=argparse.REMAINDER', and other about 'parse_known_args()'.
I'm not entirely happy with the format
paul j3 added the comment:
I changed the reference to the optparse allow_interspersed_args attribute to
the disable_interspersed_args() method.
--
Added file: http://bugs.python.org/file29662/remainder.patch
___
Python tracker rep...@bugs.python.org
paul j3 added the comment:
The optparse page gives a reason for disable_interspersed_args():
Use this if you have a command processor which runs another command which has
options of its own and you want to make sure these options don’t get confused.
For example, each command might have
paul j3 added the comment:
The test file, test_argparse.py, has a test case for this:
'class TestOptionalsActionAppendWithDefault'
argument_signatures = [Sig('--baz', action='append', default=['X'])]
successes = [
('--baz a --baz b', NS(baz=['X', 'a', 'b
paul j3 added the comment:
Oops, I was wrong about this:
Argparse doesn't prohibit all interspersed positionals. You could, for
example, have one or more positionals with other nargs that could be
interspersed. But the REMAINDER one has to be last.
parser.add_argument
paul j3 added the comment:
Looking further at test_argparse.py, I should say that the behavior of multiple
positionals when there is one cluster of positional argstrings is well
illustrated in the tests. It's the behavior when there are multiple clusters
(interspersed positionals) that can
paul j3 added the comment:
There are several problems with the patch provided in msg156315
This description:
Added patch so that only the first '--' is removed by an argparse.PARSE or
argparse.REMAINDER argument.
should read
Added patch so that only the first '--' is removed by arguments
paul j3 added the comment:
There's another 'feature' to the patch proposed here. It only deletes the
first '--' in the list of strings passed to '_get_values' for a particular
action.
parser = argparse.ArgumentParser()
parser.add_argument('foo')
parser.add_argument('bar', nargs
paul j3 added the comment:
I am working on an alternative solution that moves the '--' removal to the
consume_positionals() method, and only does it if there is a corresponding '-'
in the arg_strings_pattern.
--
___
Python tracker rep
paul j3 added the comment:
I think this problem arises from a change made in
http://bugs.python.org/issue10424
Changeset to default (i.e. development) is
http://hg.python.org/cpython/rev/cab204a79e09
Near the end of _parse_known_args it removes a:
if positionals:
self.error(_('too
paul j3 added the comment:
Further observations:
parser.add_subparsers() accepts a 'dest' keyword arg, but not a 'required' one.
Default of 'dest' is SUPPRESS, so the name does not appear in the Namespace.
Changing it to something like 'command' will produce an entry, e.g.
Namespace(command
paul j3 added the comment:
This patch addresses both issues raised here:
- throw an error when the subparser argument is missing
- allow the subparser argument to be optional
argparse.py:
_SubParsersAction -
add 'required=True' keyword.
name(self) method - creates a name of the form
paul j3 added the comment:
This patch removes only one '--', the one that put a '-' in the
'arg_strings_pattern'. It does this in 'consume_positionals' right before
calling 'take_action'. As before it does not do this if nargs is PARSER or
REMAINDER.
test_argparse.py has two
paul j3 added the comment:
This patch permits the mixing of optionals with positionals, with the caveat
that a particular positional cannot be split up.
If:
parser = ArgumentParser()
parser.add_argument('-f','--foo')
parser.add_argument('cmd')
parser.add_argument('rest', nargs
paul j3 added the comment:
It does shift the error from parse_args to add_argument, but the message
'ValueError: length of metavar tuple does not match nargs', indicates that it's
a side effect of checking on the tuple form of `metavar`.
http://bugs.python.org/issue9348
There is still room
paul j3 added the comment:
I've experimented with an argparse adaptation of profile.py:
parser = argparse.ArgumentParser(usage=usage)
parser.add_argument('-o', '--outfile', dest=outfile,
help=Save stats to outfile, metavar=path)
parser.add_argument('-s', '--sort', dest=sort
paul j3 added the comment:
In this example:
p.add_argument('--foo', nargs='*', default=None)
p.parse_args([])
Namespace(foo=None)
p.parse_args(['--foo'])
Namespace(foo=[])
'p.parse_args([])' just assigns the default to 'foo' in the Namespace.
p.parse_args(['--foo
paul j3 added the comment:
The problem isn't with REMAINDER, but with the distinction between optionals
and arguments. If you change '--def' to 'def', the parse should work:
p = ArgumentParser(prog='test.py')
p.add_argument('remainder', nargs=argparse.REMAINDER)
p.parse_args(['def
paul j3 added the comment:
Here's a way of passing an optional-like argument to a subparser:
parser = argparse.ArgumentParser()
subparsers = parser.add_subparsers(dest='cmd')
sub1 = subparsers.add_parser('cmd')
sub1.add_argument('foo',nargs='*')
args = parser.parse_args('cmd
paul j3 added the comment:
An alternative to Jason's example:
parser = argparse.ArgumentParser()
parser.add_argument('app')
parser.add_argument('--config')
parser.add_argument('app_args', nargs=argparse.REMAINDER)
args = parser.parse_args(['--config', 'bar', 'app'])
print vars(args
paul j3 added the comment:
By the way, parser.parse_args() uses parse_known_arg(). parse_known_args
returns a Namespace and a list of unknown arguments. If that list is empty,
parse_args returns the Namespace. If the list is not empty, parse_args raises
an error.
So parse_known_args does
paul j3 added the comment:
parser = argparse.ArgumentParser()
parser.add_argument('-k','--known',action='store_true')
print(parser.parse_known_args(['-k','-u']))
print(parser.parse_known_args(['-ku']))
print(parser.parse_known_args(['-uk']))
I think you want these 3 cases
paul j3 added the comment:
The 'subparsers' object has a _parser_class attribute that is normally set to
the class of the parent parser. In the attached file I create a
class CustomParser(argparse.ArgumentParser)
that makes a parser instance which copies all of the attributes
paul j3 added the comment:
Glenn
Take a look at http://bugs.python.org/issue15427
I took a stab at changing the documentation, including recommending
parse_known_args when porting optparse uses.
--
___
Python tracker rep...@bugs.python.org
http
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14364
___
___
Python-bugs-list mailing list
paul j3 added the comment:
I submitted a patch to http://bugs.python.org/issue9253
The reason why subparser became optional in the latest release is that a old
test for missing positionals was phased out, and new one added. Subparsers
have always had a default 'required=False', but the old
paul j3 added the comment:
The patch that I recently submitted for http://bugs.python.org/issue13922
appears to solve this issue. It only removes the '--' that marked the end of
options.
With:
parser = argparse.ArgumentParser()
parser.add_argument('-f','--foo')
print(parser.parse_args
paul j3 added the comment:
The attached file has a 'parse_intermixed_args()' that has the same API as
'parse_known_args()'.
It follows the two parse step model
args, remaining_args = optionals.parse_known_args()
args, extras = positionals.parse_known_args(remaining_args, args)
except
paul j3 added the comment:
This nargs test using the formater applies only when the container has a help
formatter. That is true for a ArgumentParser, but not for an argument_group.
group = parser.add_argument_group('g')
group.add_argument('bar', nargs='test')
does not raise an error
paul j3 added the comment:
Yes, http://bugs.python.org/msg166175 does use 'parse_args' in the second call.
But I think things would be more flexible if we had a second function:
def parse_???(self, args=None, namespace=None):
args, argv = self.parse_intermixed_args(args, namespace
paul j3 added the comment:
This patch adds a value test for nargs during add_argument. The core of the
new test is in ArgumentParser._check_argument.
add_argument() now calls ArgumentParser._check_argument(), which calls
_format_args(). If it gets a TypeError, it raises a metavar ValueError
paul j3 added the comment:
The attached test_nargswarn.py file tests the argparse.py patch. It tries out
various nargs values, both for parsers, groups, and mutually exclusive groups.
I intend to recast these to work in test_argparse.py
--
Added file: http://bugs.python.org
paul j3 added the comment:
This is a revision of yesterday's patch. It includes a couple of test cases
that check that parser, groups, and exclusive groups all produce the error
message.
I also changed the metavar tuple case to return an ArgumentError, and changed
test_argparse.py
paul j3 added the comment:
http://bugs.python.org/issue9849
also deals with nargs values. However there the focus is on string values like
'1', not whether an integer value can be 0 or 0.
I submitted a patch that moves the nargs testing to a
ArgumentParser._check_argument() method. It still
paul j3 added the comment:
An integer nargs value is only used in one of 2 ways,
range(nargs)
'%s'*nargs
In both a negative value acts the same as a 0.
I don't think the original authors though much about 'what if the code user
gives a negative value?', because nargs is counting things
paul j3 added the comment:
Correction: The patch I gave in the last message produces:
parser.parse_known_args(['-ku'])
(Namespace(known=False), ['u'])
It doesn't take action on the '-k', and puts 'u' in extras, not '-u'.
This new patch gets it right:
parser.parse_known_args
paul j3 added the comment:
Looks like the
text = text.strip()
at the end of the set of regex (in _format_actions_usage) needs to be replaced
with something that removes all excess spaces, e.g.
text = _re.sub( '\s+', ' ', text ).strip()
--
nosy: +paul.j3
paul j3 added the comment:
In the test case: class TestMutuallyExclusiveManySuppressed
even with a short 'eggs' argument, there is a difference
Old usage would be:
usage: PROG [-h] [--eggs EGGS]
new
usage: PROG [-h] [--eggs EGGS]
i.e. 2 v 1 space. But extra spaces are not as dramatic
paul j3 added the comment:
I see three solutions -
1) gholms' patch which removes '() ' and [] '
2) Yogesh's patch which removes all duplicated spaces.
3) remove the 2 asserts.
The first 2 do the same thing most of the time, but may differ if the user
somehow inserts spaces into names
paul j3 added the comment:
This is a revision of the test_intermixed.py that I submitted earlier. Now
`parse_intermixed_args` acts like `parse_args', and calls
`parse_known_intermixed_args`. Again it is form that can exercise the idea
without modifying `argparse.py`.
If the parser has
paul j3 added the comment:
This is the formal patch corresponding to the `test_intermixed.py`. It
includes changes to `argparse.rst`, plus tests in `test_argparse.py`. These
tests are near the end, after those for `parse_known_args`. They are roughly
equivalent to the examples
paul j3 added the comment:
Wouldn't it be simpler to use the re {m,n} notation to grab the appropriate
number of arguments?
In ArgumentParser _get_nargs_pattern we could add:
+# n to m arguments, nargs is re like {n,m}
+elif is_mnrep(nargs):
+nargs_pattern
paul j3 added the comment:
I think this patch should build on http://bugs.python.org/issue9849, which
seeks to improve the error checking for nargs. There, add_argument returns an
ArgumentError if the nargs value is not a valid string, interger, or it there
is mismatch between a tuple
paul j3 added the comment:
This patch adds this `nargs='{m,n}'` or `nargs=(m,n)` feature.
It builds on the `better nargs error message` patch in
http://bugs.python.org/msg187754
It includes an argparse.rst paragraph, changes to argparse.py, and additions to
test_argparse.py.
The tests
paul j3 added the comment:
'parse_fallback_args()' function is only in the 'test_intermixed.py' file, not
the patch. It should be in the 'if __name__' section of that file, along with
the modified 'exit()' method, since it is part of these testing suit, not meant
to be imported
paul j3 added the comment:
I should note one caveat:
As a consequence of setting nargs to 0 for the first 'parse_know_args' step,
all positional entries in the namespace get an empty list value ([]). This is
produced by 'ArgumentParser._get_values'. With the builtin action classes
paul j3 added the comment:
I'm following a dozen argparse issues with patches. I haven't seen much
posting by argparse experts (like bethard, david.murry) since last December.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
paul j3 added the comment:
I was wondering about that block of code earlier.
It would be a good idea to look at what func() does, just to make sure there
aren't any side effects - e.g. set maximum line length, required indention, etc.
--
nosy: +paul.j3
1 - 100 of 773 matches
Mail list logo
