Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue16418>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
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
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 that
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&
Changes by paul j3 :
--
components: +Library (Lib)
type: -> behavior
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue18349>
___
___
Py
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
<http:
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 l
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
_
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&#
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
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 be
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
<http://bug
paul j3 added the comment:
I just posted a patch to http://bugs.python.org/issue16468 that uses (and
tests) this fix.
--
___
Python tracker
<http://bugs.python.org/issue18
paul j3 added the comment:
The patch I just posted to http://bugs.python.org/issue16468 uses this fix.
--
___
Python tracker
<http://bugs.python.org/issue9
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_
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:
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, opti
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:
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 that if a
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue11874>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
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 als
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
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
re
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
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 it is not
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 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue18467>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
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,
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&#x
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue14074>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
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
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).&qu
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 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue12806>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue13280>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue15428>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
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
<http
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue15112>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
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 diff
Changes by paul j3 :
Added file: http://bugs.python.org/file29880/mixed.patch
___
Python tracker
<http://bugs.python.org/issue14191>
___
___
Python-bugs-list mailin
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 logi
Changes by paul j3 :
Removed file: http://bugs.python.org/file29880/mixed.patch
___
Python tracker
<http://bugs.python.org/issue14191>
___
___
Python-bugs-list mailin
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
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
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 i
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
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(req
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
<http://bugs.python.o
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 fro
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?
paul j3 added the comment:
The relevant code is:
prog = _os.path.basename(_sys.argv[0])
--
___
Python tracker
<http://bugs.python.org/issue20970>
___
___
paul j3 added the comment:
Cross reference for sys.argv[0] is
http://docs.python.org/3.4/library/sys.html
> ___
>
--
___
Python tracker
<http://bugs.python.org/i
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue14156>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
>From http://bugs.python.org/issue14156
"argparse.FileType for '-' doesn't work for a mode of 'rb'"
I learned that 'stdin/out' can be embedded in an 'open' by using the 'fileno()'
and 'clos
paul j3 added the comment:
A related issue http://bugs.python.org/issue13824
"argparse.FileType opens a file and never closes it"
I proposed a FileContext class that returns a `partial(open, filename,...)'
context object. The issues of how to deal with stdin/
paul j3 added the comment:
There are a couple of complications to using 'fileno'.
We probably don't want to close 'sys.stdin' or 'sys.stdout' (not even if they
are redirected to other files?). That means using:
open(sys.stdin.fileno(), ..., closefd=F
paul j3 added the comment:
http://stackoverflow.com/questions/22929087
A question that could be addressed with this patch(es)
In a subparser:
I have 4 arguments: -g, -wid, -w1, and -w2.
-w1 and -w2 always appear together
-wid and (-w1 -w2) are mutually exclusive, but one or the
paul j3 added the comment:
While 'argparse' is complex, its organization is quite different from
'itertools'. For most purposes there is one starting point:
parser = argparse.ArgumentParser(...)
Nearly everything else invokes a 'parser' method. Most comple
paul j3 added the comment:
http://stackoverflow.com/questions/22990977/why-does-this-argparse-code-behave-differently-between-python-2-and-3
is answered by this change in how `required` arguments are tested, and how
subparsers fell through the cracks
paul j3 added the comment:
While mutually exclusive groups are a subclass of argument groups, they have
very different uses.
Argument groups are used solely to organize the help section. Groups are not
used at all during parsing. 'parse_args' doesn't even pay attention to t
paul j3 added the comment:
Using a mutually_exclusive_group is a little more complicated than I implied in
the previous post.
p=argparse.ArgumentParser()
g=p.add_mutually_exclusive_group()
# currently the code objects to 'title' and 'description' keywords
g
paul j3 added the comment:
The attached file implements a solution using a subclassed ArgumentParser and a
.add_titled_mutually_exclusive_group method (two versions).
I changed the test conditions a bit, removing a blank line, and making the
usage 'exclusive'.
--
Added
paul j3 added the comment:
The idea of nesting a mutually_exclusive_group in a titled argument_group is
already present in `test_argparse.py`.
class TestMutuallyExclusiveInGroup(MEMixin, TestCase):
def get_parser(self, required=None):
parser = ErrorRaisingArgumentParser(prog
paul j3 added the comment:
oops - one more glitch (revealed by TestMutuallyExclusiveInGroup):
'add_mutually_exclusive_group' accepts a 'required' argument, but
'add_argument_group' does not. So 'add_titled_mutually_exclusive_group' needs
to be changed
paul j3 added the comment:
Another example of code hitting this AssertionError. Here the problem was a
space in the option argument, '--out '.
http://stackoverflow.com/questions/23159845/python-argparse-assertionerror
'parser.add_argument('-o', '--out '
paul j3 added the comment:
http://bugs.python.org/issue14191
implements the other side of optparse behavior - allowing a complete
intermixing of optionals and positionals.
It does that with a new 'ArgumentParser.parse_intermixed_args()
paul j3 added the comment:
http://bugs.python.org/issue15112
breaks one test that I added to issue
+class TestPositionalsAfterOptionalsPlus(ParserTestCase):
+"""Tests specifying a positional that follows an arg with nargs=+
+http://bugs.python.org/issu
Changes by paul j3 :
Added file: http://bugs.python.org/file35028/format_usage.patch
___
Python tracker
<http://bugs.python.org/issue11874>
___
___
Python-bugs-list mailin
Changes by paul j3 :
Removed file: http://bugs.python.org/file30941/format_usage.patch
___
Python tracker
<http://bugs.python.org/issue11874>
___
___
Python-bugs-list m
paul j3 added the comment:
This patch adds a ReGroupHelpFormatter class, which regroups positional
arguments in the usage line as discussed before. It builds on the reworked
usage formatter in bugs/python.org/issue11874 (which keeps usage as a list
longer).
For a complicate parser, usage
paul j3 added the comment:
This is a testing script for this patch. It is not a unit test.
Example:
p = argparse.ArgumentParser()
p.formatter_class = argparse.ReGroupHelpFormatter
p.add_argument('foo')
p.add_argument('arg1',nargs='?')
p.add_ar
paul j3 added the comment:
oops - to fix the error message that OP complained about, I need to patch
'_get_action_name' as well:
def _get_action_name(argument):
...
elif argument.metavar not in (None, SUPPRESS):
metavar = argument.metavar
if
paul j3 added the comment:
This patch fixes both help and error formatting.
A module level '_format_metavars' does the formatting for both.
I have tried several alternatives, including using the 'usage' style.
There is similarity between this fix and that for issue 1
paul j3 added the comment:
Another Stackoverflow question triggered by this issue
http://stackoverflow.com/questions/23349349/argparse-with-required-subparser
--
___
Python tracker
<http://bugs.python.org/issue9
paul j3 added the comment:
There's a complicating issue - should these default values be passed through
the type function?
In most cases in `_get_values`, the string first goes through `_get_value`, and
then to `_check_value`.
For example the 'else:' case:
Changes by paul j3 :
Added file: http://bugs.python.org/file35128/notes.txt
___
Python tracker
<http://bugs.python.org/issue9625>
___
___
Python-bugs-list mailin
paul j3 added the comment:
I encountered a conflict when merging this patch with
http://bugs.python.org/issue15112. In my first testcase, 'cmd' and 'rest'
failed the 'required' test in phase one of 'intermixed'. That's because 15112
postponed par
paul j3 added the comment:
Update the patch -
test_argparse.py - cleanup spaces
argparse.rst - merging conflicts
--
Added file: http://bugs.python.org/file35190/issue14910_2.patch
___
Python tracker
<http://bugs.python.org/issue14
Changes by paul j3 :
Removed file: http://bugs.python.org/file35190/issue14910_2.patch
___
Python tracker
<http://bugs.python.org/issue14910>
___
___
Python-bugs-list m
Changes by paul j3 :
Added file: http://bugs.python.org/file35191/issue14910_2.patch
___
Python tracker
<http://bugs.python.org/issue14910>
___
___
Python-bugs-list mailin
paul j3 added the comment:
When `add_subparsers` creates the `_prog_prefix` it uses a list of positionals.
That makes sense, since a subparser argument is positional, so the user needs
to know where it fits in the broader scope of positionals.
But it intentionally skips the 'optionals&#
Changes by paul j3 :
Added file: http://bugs.python.org/file35204/sample.py
___
Python tracker
<http://bugs.python.org/issue20333>
___
___
Python-bugs-list mailin
paul j3 added the comment:
An alternative to passing a Formatter instance to the parser is to use a
wrapper function. `HelpFormatter.__init__` takes several keyword args.
'_get_formatter' does not use those. However we could define:
def format_wrapper(**kwargs):
# clas
paul j3 added the comment:
An alternative to adding a 'ParagraphFormatter' class to 'argparse', is to
format the individual text blocks PRIOR to passing them to the 'parser', and
use the 'RawTextHelpFormatter'.
In the attached script I use a simple
Changes by paul j3 :
Added file: http://bugs.python.org/file35306/wrap_sample.py
___
Python tracker
<http://bugs.python.org/issue12806>
___
___
Python-bugs-list mailin
Changes by paul j3 :
Removed file: http://bugs.python.org/file35236/wrap_sample.py
___
Python tracker
<http://bugs.python.org/issue12806>
___
___
Python-bugs-list mailin
paul j3 added the comment:
Last year someone asked on Stackoverflow about using 'type=bool'. My answer is
at:
http://stackoverflow.com/questions/15008758/parsing-boolean-values-with-argparse/19233287#19233287
'type' is supposed to be a function that takes a string, and co
paul j3 added the comment:
Two points to keep in mind:
'argparse' works with 'sys.argv[1:]'. If that does not contain what you want,
then you can pass your own 'argv' to 'parse_args'.
'type=bytes' means, call the builtin 'bytes'
paul j3 added the comment:
'invalid bytes value' is the error message generated by 'argparse'. The
underlying error (for a string like 'xxx') is:
print(bytes(sys.argv[1]))
TypeError: string argument without an encoding
You could use 'bytes' i
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue10523>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
If we make this change to '_StoreAction', we need to do it to 4 other
subclasses which take the same 'setattr(namespace, self.dest, values)'.
An alternative would be to define a 'Namespace' function that does this
conditional 's
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue9351>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
In the attached file I tried another approach - a custom Action class. It
gives you the custom behavior now, instead of 2-3 releases in the future.
class Action2(Action):
# custom action
def __init__(self, *args, **kwargs):
super
301 - 400 of 778 matches
Mail list logo
