Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14156
___
___
Python-bugs-list mailing list
paul j3 added the comment:
Cross reference for sys.argv[0] is
http://docs.python.org/3.4/library/sys.html
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20970
paul j3 added the comment:
Yes, the documentation is accurate but a bit vague. It doesn't say how 'it
uses sys.arg[0]'. The example implies it uses 'basename'. So the question is,
whether that implementation detail should be more explicit?
--
nosy: +paul.j3
paul j3 added the comment:
The relevant code is:
prog = _os.path.basename(_sys.argv[0])
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20970
paul j3 added the comment:
A couple more thoughts on an expanded argument testing mechanism:
- do we need both 'seen_actions' and 'seen_non_default_actions'?
'seen_actions' is used only to test whether all required actions have been
seen. These 2 sets differ in how positionals
paul j3 added the comment:
I need to tweak the last patch so 'using_default' is also set when an
nargs='*' positional is set to the '[]' default.
if action.default is not None:
value = action.default
+using_default = True
else
paul j3 added the comment:
In http://bugs.python.org/issue11588 (Add necessarily inclusive groups to
argparse) I propose a generalization to these testing groups that would solve
your 'conflicter' case as follows:
usage = 'prog [ --conflicter | [ --opt1 ] [ --opt2 ] ]'
parser
paul j3 added the comment:
The addition of a simple decorator to the 'ArgumentParser' class, would
simplify registering the tests:
def crosstest(self, func):
# decorator to facilitate adding these functions
name = func.__name__
self.register('cross_tests', name
paul j3 added the comment:
This is an example of using 'patch_w_mxg2.diff' to handle the inclusive group
case proposed by the OP.
Since 'seen_non_default_actions' (and 'seen_actions') is a set of 'Actions', it
is convenient to use 'set' methods with pointers to the actions that a
collected
paul j3 added the comment:
This patch uses:
tests = self._registries['cross_tests'].values()
to get a list of functions to run at the end of '_parse_known_args'.
I replaced all of the mutually_exclusive_group tests (3 places) in the
ArgumentParser with a static function defined in class
paul j3 added the comment:
This patch corrects the handling of `seen_non_default_action` in another case -
a positional with '?' and `type=int` (or other conversion).
if
parser.add_argument('badger', type=int, nargs='?', default=2) # or '2'
and the original test 'seen_non_default_actions
paul j3 added the comment:
The suggestion in this issue is to add a 'mutually_inclusive_group' mechanism,
one that would let users specify that certain sets of arguments must occur
together. Furthermore there was mention of allowing some sort of nesting.
Modeling
paul j3 added the comment:
Regarding a usage line like:
(-o FILE | (-O DIR (-p PATTERN | -s SUFFIX))
The simplest option is to just a custom written 'usage' parameter.
With the existing HelpFormatter, a nested grouping like this is next to
impossible. It formats the arguments (e.g.'-O
paul j3 added the comment:
The attached file shows how the default argument groups could be redefined,
using 'required' as the criteria.
I've implemented it as a method that is added to a subclass of ArgumentParser.
This method is invoked after arguments are defined, prior to generating
paul j3 added the comment:
Here's another possible solution: add a `help_groups` parameter to
ArgumentParser. It is a list of base argument group names.
`parser.add_argument(...)' places the action in one of those groups.
This is a generalization of the current code which creates two groups
Changes by paul j3 ajipa...@gmail.com:
Added file: http://bugs.python.org/file34074/alt_grouping2.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9694
paul j3 added the comment:
As Steven pointed out, the existing `add_argument_group` mechanism can be used
to group required arguments. For example
- temp.py --
parser = argparse.ArgumentParser(description = 'Do something')
group1
paul j3 added the comment:
In argparse.py the status of ArgumentTypeError is ambiguous.
ArgumentError is listed as a public class, ArgumentTypeError is not. It also
says 'All other classes in this module are considered implementation details.'
ArgumentTypeError is a subclass of Exception
paul j3 added the comment:
Normally the unix shell takes care of this expansion. If I call a simple
script that prints sys.argv and runs a simple parser, I get:
2135:~/mypy$ python2.7 filetypetest.py ~/mypy/test.txt
['filetypetest.py', '/home/paul/mypy/test.txt']
Namespace(file
paul j3 added the comment:
With a minor tweak to `argparse._is_mnrep()`, `nargs='{3}'` would also work.
This means the same as `nargs=3`, so it isn't needed. But it is consistent
with the idea of accepting Regular Expression syntax where it makes sense.
`nargs='{2,3}?'` also works, though
paul j3 added the comment:
`parse_args` just calls `parse_known_args`, and then raises an error if `rest`
is not empty. So it is `parse_known_args` that is doing the abbreviation
matching.
Abbreviation matching is done relatively early, when `_parse_known_args` first
loops through
paul j3 added the comment:
For a programmer who needs to turn off this abbreviation matching now, a simple
solution is to subclass ArgumentParser:
class MyParser(ArgumentParser):
def _get_option_tuples(self, option_string):
return []
This could be the place
paul j3 added the comment:
http://stackoverflow.com/a/20167038/901925
is an example of using `_parser_class` to produce different behavior in the
subparsers.
parser = ArgumentParser()
parser.add_argument('foo')
sp = parser.add_subparsers(dest='cmd')
sp._parser_class = SubParser
paul j3 added the comment:
f.nargs = '?'
f.default = argparse.SUPPRESS
f.help = argparse.SUPPRESS
may be best set of tweaks to a positional Action `f`. In quick tests it
removes `f` from the help, suppresses any complaints about a missing string,
and does not put anything
paul j3 added the comment:
`argparse.SUPPRESS` should do the trick. According to the documentation it can
be used with `default` and `help` parameters.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19462
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:
Just hang on the Action object that the `add_argument` returned, and change its
`help` attribute.
a = parser.add_argument('--foo', help='initial help')
a.help = 'new help'
If using a custom parser class and subclass, I'd do something like
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:
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:
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:
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:
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:
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:
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
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:
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
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:
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:
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:
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
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:
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/issue15428
___
___
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/issue12806
___
___
Python-bugs-list mailing list
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/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:
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
paul j3 added the comment:
This patch produces the same usage as before, but I have rewritten
_format_actions_usage() for both HelpFormatter and MultiGroupFormater.
The original HelpFormatter._format_actions_usage() formats the actions, splices
in group markings, cleans up the text, if needed
paul j3 added the comment:
Here's a patch that takes a different approach - rewrite
_format_actions_usage() so it formats groups (and unattached actions) directly.
It uses the same logic to determine when to format a group, but then it calls
_format_group_usage() to format the group
paul j3 added the comment:
I just submitted at patch to http://bugs.python.org/issue11874 that takes care
of this issue as well.
I rewrote _format_actions_usage() so it formats the parts directly, so there is
no need cleanup or parse the full text string
paul j3 added the comment:
I just submitted a patch to http://bugs.python.org/issue11874 which rewrites
_format_actions_usage(). It now formats the groups and actions directly,
keeping a list of these parts. It no longer has to cleanup or split a usage
line into parts. So
paul j3 added the comment:
I just submitted a patch to http://bugs.python.org/issue11874 that
substantially rewrites _format_actions_usage(). It generates the group and
action parts separately, and does not do the kind of cleanup that produces this
issue
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18467
___
___
Python-bugs-list mailing list
paul j3 added the comment:
I think this example illustrates your issue:
class FooAction(argparse.Action):
def __call__(self, parser, namespace, values,
option_string = None):
if values=='Q':
setattr(namespace, self.dest
paul j3 added the comment:
This issue should also preserve a metavar like: '(one)two', i.e. '(' at the
start.
In http://bugs.python.org/issue10984 these _re replacements are applied to
individual action strings as well as the whole usage line. So if () are to be
removed from '[-h] (-y
paul j3 added the comment:
If the arg_parts are passed through the same cleanup as the 'text' (and empty
strings removed), then
text = ' '.join(arg_parts)
In that case there would be no need to return both (text, arg_parts).
Parenthesis in the metavar could also create the problem
paul j3 added the comment:
This patch adds a MultiGroupHelpFormatter that formats groups even if they
share actions or the actions are not in the same order as in the parse._actions
list. It sorts the groups so positional actions, if any appear in the correct
order.
A long test case
paul j3 added the comment:
I just filed a patch with http://bugs.python.org/issue10984 (argparse
add_mutually_exclusive_group should accept existing arguments to register
conflicts) that includes the latest patch from this issue. I tweaked it so
_format_actions_usage only returns arg_parts
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11874
___
___
Python-bugs-list mailing list
paul j3 added the comment:
While playing with some examples, I found that exclusive group formatting has
another failure case. If the usage line is long enough to wrap, optionals and
positionals are formatted separately, with positionals appearing on a separate
line(s). That means
paul j3 added the comment:
One usage option is to make a subclass of HelpFormatter (the accepted way of
customizing a formatter), and write a function that formats each group
independently. For the example case, the resulting format might be:
usage: PROG [-h] [-b] [-a | -c] [-a | -d]
-h
paul j3 added the comment:
This approach of simply adding the existing actions to the group's
_group_actions works fine, at least when it comes catching the error.
It may be difficult to get a useful usage line. In usage, arguments appear in
the order in which they were created, optionals
paul j3 added the comment:
This patch generally deals with the choices option, and specifically the
problems with formatting long lists, or objects that have __contains__
but not __iter__. But it also incorporates issues 9849 (better add_argument
testing) and 9625 (choices with *). It may
paul j3 added the comment:
I just posted a patch to http://bugs.python.org/issue16468 that deals with this
'bc' in 'abc' issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16977
paul j3 added the comment:
I just posted a patch to http://bugs.python.org/issue16468 that uses (and
tests) this fix.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18349
paul j3 added the comment:
The patch I just posted to http://bugs.python.org/issue16468 uses this fix.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9625
paul j3 added the comment:
In the patch I just posted to http://bugs.python.org/issue16468 I address this
long list issue in several ways:
In the Usage line, the metavar gives the user an alternative
In the expanded help line the user can just omit the '%(choices)s'
In _check_value(), I
paul j3 added the comment:
I included this patch (with minor changes) in a patch that I just posted to
http://bugs.python.org/issue16468. That issue deals with the argument choices
option, which can be tested along with nargs and metavars
paul j3 added the comment:
Changing _check_value from:
def _check_value(self, action, value):
# converted value must be one of the choices (if specified)
if action.choices is not None and value not in action.choices:
...
to
def _check_value(self, action
New submission from paul j3:
As discussed in issue 16468, a metavar may be used to provide an alternative
representation of a choices option. However if a metvar like 'range(20)' is
used, usage formatter strips off the '()'.
parser.add_argument('foo', type=int,
choices=range(20
Changes by paul j3 ajipa...@gmail.com:
--
components: +Library (Lib)
type: - behavior
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18349
paul j3 added the comment:
There still is one choices='XYZ' example (16.4.5.1. Sub-commands) but the
focus isn't on choices.
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16933
paul j3 added the comment:
test_argparse.py has some choices='abc' cases.
In those should parser.parse_args(['--foo','bc']) be considered a success or
failure?
The underlying issue here is that while string iteration behaves like list
iteration, string __contains__ looks for substrings
paul j3 added the comment:
Change choices='abc' to choices=['a', 'b', 'c'], as discussed in issue
16977 (use of string choices is a bad example)
--
Added file: http://bugs.python.org/file30762/issue9625_2.patch
___
Python tracker rep
paul j3 added the comment:
I'd suggest not worrying about the default metavar in the _expand_help()
method. The formatted choice string created in that method is only used if the
help line includes a '%(choices)s' string. The programmer can easily omit that
if he isn't happy
paul j3 added the comment:
chris.jerdonek wrote:
Also, to answer a previous question, the three places in which the choices
string is used are: in the usage string (separator=','), in the help string
when expanding %(choices)s (separator=', '), and in the error message text
(separator
paul j3 added the comment:
The exit and error methods are mentioned in the 3.4 documentation, but there
are no examples of modifying them.
16.4.5.9. Exiting methods
ArgumentParser.exit(status=0, message=None)
ArgumentParser.error(message)
test_argparse.py has a subclass
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16418
___
___
Python-bugs-list mailing list
paul j3 added the comment:
I've added 2 more tests,
one with default='c', which worked before.
one with default=['a','b'], which only works with this change.
http://bugs.python.org/issue16878 is useful reference, since it documents
the differences between nargs=? and nargs
601 - 700 of 773 matches
Mail list logo
