Steven Bethard added the comment:
Yeah, looks like we can close this. If anyone finds a specific bug in the use
of SUPPRESS, please open a new issue.
--
resolution: -> duplicate
status: open -> closed
superseder: -> document argparse's
Steven Bethard added the comment:
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue15935>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steven Bethard added the comment:
Patch, with the basestring amendment, looks good.
> Do we need a new test for conversion of string defaults?
Yeah, I guess go ahead and add one. That will at least document our intentions
here, and if we decide to change that later, then it will force us
Steven Bethard added the comment:
Ok, sounds good. Let's make the test check the documented behavior, and then
add back the isinstance(action.default, str) check.
--
___
Python tracker
<http://bugs.python.org/is
Steven Bethard added the comment:
I see. So right now, both string defaults and non-string defaults are being
converted with the type= function. That seems suspect to me since the
documentation explicitly says "type= can take any callable that takes a single
string argument and return
Steven Bethard added the comment:
Oh, I see, you're right - the recent changes from the Roundup Robot are exactly
the wrong changes - special casing _StoreAction, not string defaults.
--
___
Python tracker
<http://bugs.python.org/is
Steven Bethard added the comment:
I haven't been following python-dev recently, but the only discussion I
remember was for non-strings in __dict__, not non-identifiers.
--
___
Python tracker
<http://bugs.python.org/is
Steven Bethard added the comment:
It looks like the correct fix was already applied, but just to chime in here:
(1) Yes, the error is that the isinstance(action.default, str) check was lost
(2) Yes, it is intended that you can use a string value as your default and the
type= converter will be
Steven Bethard added the comment:
If you need to get things that aren't valid Python identifiers, use vars() to
get the dictionary:
http://docs.python.org/dev/library/argparse.html#the-namespace-object
Changing all non-alphanumeric characters to underscores would be a backwards
incompa
Steven Bethard added the comment:
You could try declaring a type converter and using the type= parameter of
add_argument. Your type converter could look something like:
def expanded_path(arg):
return os.path.expandvars(arg)
Would that work
Steven Bethard added the comment:
Interesting idea! The regex would need a little extra care to interoperate
properly with prefix_chars, but the approach doesn't seem crazy. I'd probably
call the constructor option something like "args_default_to_positional" (the
Steven Bethard added the comment:
The fix looks about right to me.
There's a bug in the tests though:
parser.parse_args(('x'))
should probably be:
parser.parse_args(('x',))
since I assume the intent was to test tuples.
--
_
Steven Bethard added the comment:
It's a bug, but it's already been reported in Issue 12776. There's a patch
there, but someone needs to commit it.
--
superseder: -> argparse: type conversion function should be called only once
Changes by Steven Bethard :
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15832>
___
___
Python-bugs-
Steven Bethard added the comment:
@gcbirzan: Could you please open up a new issue? The current issue is fixed -
it's just that the fix caused a new issue.
I would say that the `args` parameter was never intended to be anything but a
list, so currently there's a documentation bug
Steven Bethard added the comment:
I've updated the patch for the current trunk. Should be ready to commit.
--
Added file: http://bugs.python.org/file26490/Issue13249-4.patch
___
Python tracker
<http://bugs.python.org/is
Steven Bethard added the comment:
Ok, here's what I think needs to go into the documentation here:
(1) Add a separate section to the argparse docs about '--'. Give examples like
the ones in this issue, and show how '--' can solve them
(2) Cross-reference the s
Steven Bethard added the comment:
And I guess Issue 9182 is the right place for (1).
--
___
Python tracker
<http://bugs.python.org/issue9338>
___
___
Python-bug
Steven Bethard added the comment:
So Kotan's patch doesn't actually solve the original problem. Instead, it
inserts the workaround into the help message of the parser. I think this is
probably not the right fix. We should probably do two things:
(1) Right now: create a documenta
Changes by Steven Bethard :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15433>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Steven Bethard :
--
resolution: -> duplicate
superseder: -> argparse optionals with nargs='+' can't be followed by
positionals
___
Python tracker
<http://bu
Steven Bethard added the comment:
Definitely a bug here. Attached is a patch and a test, based on Russell Sim's
suggestion, that should fix it.
--
keywords: +patch
versions: +Python 3.4
Added file: http://bugs.python.org/file26486/13720.
Steven Bethard added the comment:
I'm going to close this issue, since argparse is doing what you've asked it to,
even if that wasn't what you expected.
But I think the documentation for this kind of thing could be improved. If
you'd like to help document the workaround f
Steven Bethard added the comment:
If you'd like to help improve the documentation so that the workaround for your
problem is more obvious, please contribute to Issue 15428.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Steven Bethard :
Several bugs (e.g. Issue 15327 and Issue 15271) have been filed suggesting that
people aren't really clear on how argparse handles argument name collisions or
how they can get it to do what they want.
I think these problems could probably be solved
Steven Bethard added the comment:
I don't think there's any easy way for argparse to automatically do what you
want. However, there's a simple workaround - just use the dest= argument and
specify two different destinations:
>>> parser = argparse.ArgumentParser()
Steven Bethard added the comment:
I'm changing the title because I keep seeing duplicates.
Documentation patches still welcome!
--
title: argparse: Default Help Message Lists Required Args As Optional ->
argparse required arguments displayed under "optional argume
Changes by Steven Bethard :
--
resolution: -> duplicate
status: open -> closed
superseder: -> argparse: Default Help Message Lists Required Args As Optional
___
Python tracker
<http://bugs.python.or
Steven Bethard added the comment:
Thanks for working on this! I think keeping the first example as simple is
possible is probably a good idea. And I didn't have time to read through the
whole patch, but as far as I went, the pizza examples looked
Steven Bethard added the comment:
I'm sympathetic to the idea that '-' should be translated similarly for
optional and positional arguments, but as you've noted, it would be a risky
patch because it's already possible for people to use getattr on hyphenated
argumen
Steven Bethard added the comment:
I don't think this is a bug. You've specified two arguments with the same
destination, "foo". This means that argparse will parse the first one, assign
it to the attribute "foo" and then parse the second one and assign it
Steven Bethard added the comment:
I created Issue 15427 for the parse_args documentation bug. So let's make this
issue just about parsing intermixed arguments.
Yes, if someone would like to provide a patch for this, please create a method
"parse_intermixed_args" rather than a
New submission from Steven Bethard :
>From http://bugs.python.org/issue14191#msg155202:
ArgumentParser.parse_args(args=None, namespace=None)
...
However, nowhere is the args= parameter explained. One example is given at the
end of 15.4.4.6 showing the use of args= which apparently accept
Steven Bethard added the comment:
Your patch is a good start, but it needs to handle all the related situations,
e.g. nargs='?' and the possibility of having more than one zero-length argument
at the end.
I believe the following patch achieves this. Please test it out.
-
Steven Bethard added the comment:
The tests look like they're testing the right things, but the tests should
instead be written like the rest of the argparse tests. For example, look at
TestOptionalsNargs3 and TestPositionalsNargs2. You could write your tests to
look something like
Steven Bethard added the comment:
The fix looks right, but we definitely need a test. I tried to write one, but
I'm not sure how to do this properly given how test_argparse redirects standard
input and output (so that fileno() doesn't work anymore). I've attached my
current (f
Steven Bethard added the comment:
On the off chance that someone was waiting for feedback from me, I'll say:
(1) A simple boolean --foo/--no-foo action seems useful to me. I would probably
call it BooleanOptionalAction rather than FlagAction. (Almost anything could be
considered a
Steven Bethard added the comment:
Sorry, my mistake, the doc changes were already in the patch. I just checked
them and they look good too. So everything's ready to commit.
Thanks for your contribution!
--
___
Python tracker
Steven Bethard added the comment:
I think it makes a lot of sense to allow people to disable abbreviations, so +1
on the feature request.
The patch looked good. There was one typo - using "accept_abbrev" in the
docstring instead of "allow_abbrev" as in the implementati
Steven Bethard added the comment:
Yeah, overwriting the existing parser is probably not typically what the user
intended.
However, I could see someone doing this if, say, they had a parser designed by
another module writer, and they wanted to use it but just change one of the
sub-parsers or
Steven Bethard added the comment:
I agree that this looks like a bug. I think the fix is something like the
attached patch, but it needs some tests to make sure that it fixes your problem.
--
keywords: +patch
Added file: http://bugs.python.org/file26471/issue9625.diff
Changes by Steven Bethard :
--
resolution: -> duplicate
status: open -> closed
superseder: -> argparse: Default Help Message Lists Required Args As Optional
___
Python tracker
<http://bugs.python.or
Steven Bethard added the comment:
Looks good. There was one typo in "parametres" that I've fixed. Should be ready
to apply.
--
Added file: http://bugs.python.org/file26469/11807_3.patch
___
Python tracker
<http://bugs.pyt
Steven Bethard added the comment:
The argparse changes and tests look good. The new method needs to be
documented. You can see some other things (e.g. Misc/NEWS) that also need to be
updated by running "make patchcheck" as described here:
http://docs.python.org/devguide/
Steven Bethard added the comment:
Yes, the original patch looks fine to me. I applied and tested it, and it works
as expected.
Please go ahead and apply.
--
___
Python tracker
<http://bugs.python.org/issue12
Steven Bethard added the comment:
The patch looks good to me. I've updated it for trunk and to include Mike
Meyer's additional test. All argparse tests pass.
Anyone who's able to commit and backport, please do.
(I should be able to commit myself, but it's now been too
Steven Bethard added the comment:
So I generally agree that FileType is not what you want for anything but quick
scripts that can afford to either leave a file open or to close stdin and/or
stdout. However, quick scripts are an important use case for argparse, so I
don't think we shoul
Steven Bethard added the comment:
Special casing the formatting of 'store_const' makes me nervous because
formatting is already complicated and it doesn't know anything about action
types.
But feel free to propose a patch!
In the meantime:
- propagate the default to all t
Steven Bethard added the comment:
I don't think this is going to change.
It's basically a consequence of having a unified handling of nargs='?',
nargs='*', nargs='+', etc. These will all consume as many arguments as they
can, and argparse doesn&
Steven Bethard added the comment:
I can't find anywhere in the documentation where type=bool, type=unicode or
type=long are disallowed. They shouldn't be disallowed. If you want to pass
type=bool, argparse should not stop you. And it currently doesn't:
>>> parser =
Steven Bethard added the comment:
The patch supplied was in reverse, but the bug report was correct. You can't
pass "type=string" since there's no string callable, only a str callable.
The docstring is confusing because the quotes make it looks like we mean the
string &#x
Steven Bethard added the comment:
I think the real fix needs to search recursively though all subparsers. Here's
a first draft of a patch that does this. I believe your sample code works after
this patch.
I don't have the time to turn your bug report into proper test (and add a tes
Steven Bethard added the comment:
This patch looks like the right fix to me. The tests look good too.
--
___
Python tracker
<http://bugs.python.org/issue13
Steven Bethard added the comment:
The problem is basically that _parse_known_args calls _parse_optional to
determine whether something is an optional or a positional. But _parse_optional
only checks "if arg_string in self._option_string_actions", that is, if the
string can be fo
Steven Bethard added the comment:
My mistake. I see that the error you're getting is a bad interaction between
the option in the main parser and an ambiguous option in the subparser.
--
resolution: duplicate ->
status: closed -> open
superseder: argparse: allow abbrevia
Steven Bethard added the comment:
Yep. Closing as duplicate.
--
resolution: -> duplicate
status: open -> closed
superseder: -> argparse: allow abbreviation of sub commands by users
___
Python tracker
<http://bugs.python.or
Steven Bethard added the comment:
> It prevents implementing parsers that pass strings on to another
> sub-parser or command.
...
> wouldn't you use 'parse_known_args' instead of 'parse_args'
> and pass the remaining arguments to the next script
I'll
Steven Bethard added the comment:
I just tried this with grep's "-e" and "--regexp":
$ cat > temp.txt
a--b
cdef
$ grep -e-- -v temp.txt
cdef
$ grep --regexp=-- -v temp.txt
cdef
$ grep -e -- -v temp.txt
cdef
$ grep --regexp -- -v temp.txt
cdef
And with diff's
Steven Bethard added the comment:
Ok, I agree - I'm fine with it as a bugfix. Depending on the removal of extra
-- strings would be pretty crazy anyway. ;-)
--
___
Python tracker
<http://bugs.python.org/is
Steven Bethard added the comment:
Actually, that could be even simpler:
args, remaining_args = optionals.parse_known_args()
args = positionals.parse_args(remaining_args, args)
--
___
Python tracker
<http://bugs.python.org/issue14
Steven Bethard added the comment:
Thinking about it a bit more, it strikes me that maybe you could get the
behavior you want by declaring two parsers, one with just optionals, and one
with just positionals. Then:
optional_args, remaining_args = optionals.parse_known_args()
args
Steven Bethard added the comment:
> Hence, I conclude that, unless this was spelled out in the PEP and I
> missed it, that having such boundaries is a bug
Practically speaking, we just can't change this because it will break existing
argparse scripts. Argparse has had this beh
Steven Bethard added the comment:
> optparse, which argparse attempts to replace, permitted positional
> arguments to be intermixed with optional arguments
Sure, but optparse didn't actually parse positional arguments - it just threw
them into a bag, and then you had to gro
Steven Bethard added the comment:
This behavior is intentional - positional arguments must be sequential, not
broken up with optional (flag) arguments between. So this is a documentation
bug.
Allowing positional arguments to be broken up with optional (flag) arguments
between them would be
Steven Bethard added the comment:
Yes, the problem is in FileType.__call__ - the handling of '-' is pretty
simplistic. Patches welcome.
--
___
Python tracker
<http://bugs.python.o
Steven Bethard added the comment:
> making Namespace subscriptable
This has been discussed before - see issue 11076. I prefer to keep Namespace as
simple as possible. For subscripting, just use the standard Python idiom of
vars as suggested in the docs:
http://docs.python.org/libr
Steven Bethard added the comment:
For optional flags like --foo-bar, argparse does munge the "dest" to "foo_bar",
following optparse. For positional arguments, arpgarse doesn't munge things
this way, but if you want the argument named "foo-bar" in help messa
Steven Bethard added the comment:
It's undocumented, and it begins with an underscore, but it would certainly be
safer to deprecate it first.
--
___
Python tracker
<http://bugs.python.org/is
Steven Bethard added the comment:
Looks like the problem is that "_format_action_invocation" is not being as
careful with the different possibilities for metavar as "_format_args" is.
Patches welcome!
--
___
P
Steven Bethard added the comment:
Yes, this is a known bug (Issue 11874). Patches welcome.
--
resolution: -> duplicate
superseder: -> argparse assertion failure with brackets in metavars
___
Python tracker
<http://bugs.python.org/i
Steven Bethard added the comment:
So it seems like what bash needs and what zsh needs are pretty different. My
feeling so far is that if there isn't "one true format" that argparse can
produce and be useful to a wide variety of shells, then it's probably not
functiona
Steven Bethard added the comment:
Yeah, the same issues have been discussed in Issue 4256. My feeling so far is
that if there isn't "one true format" that argparse can produce and be useful
to a wide variety of shells, then it's probably not functionality that belongs
Steven Bethard added the comment:
I think adding a new formatter for man pages would be generally useful.
Assuming someone provides a patch. ;-)
--
___
Python tracker
<http://bugs.python.org/issue14
Steven Bethard added the comment:
Oh ok. Sounds good then!
--
___
Python tracker
<http://bugs.python.org/issue14034>
___
___
Python-bugs-list mailing list
Unsub
Steven Bethard added the comment:
Yeah, the intention was that you could just override _get_args in a subclass to
get a better __repr__. I think these days all the argparse classes only have
keyword arguments, so _get_args probably isn't necessary an
Steven Bethard added the comment:
I have no objections on adding a howto, and something like the attached patch
would be fine with me (though I don't have time to review it in full and trust
you to).
You might want to coordinate with Issue 13850 a bit - they want a quick
reference
Steven Bethard added the comment:
The implementation looks along the right track. Now it just needs some tests.
--
___
Python tracker
<http://bugs.python.org/issue9
Steven Bethard added the comment:
See nargs=argparse.REMAINDER for an approach that doesn't require that first
'--':
http://docs.python.org/library/argparse.html#nargs
But yeah, removing more than one '--' is probably a bug. Fixing it would be a
little backwards i
Steven Bethard added the comment:
The idea and patch seem okay to me. Needs tests though.
--
___
Python tracker
<http://bugs.python.org/issue13966>
___
___
Pytho
Steven Bethard added the comment:
This is a new feature, not a bug, so I think the correct fix is to change the
2.7 documentation, since at this point 2.7 can only get bugfixes, not new
features.
--
___
Python tracker
<http://bugs.python.
Steven Bethard added the comment:
Sounds like an excellent plan to me too.
--
___
Python tracker
<http://bugs.python.org/issue13850>
___
___
Python-bugs-list m
Steven Bethard added the comment:
Eric's suggested doc fix looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue13685>
___
___
Python-bugs-l
Steven Bethard added the comment:
Closing then. Thanks for checking it again!
--
assignee: -> bethard
resolution: -> works for me
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
New submission from Steven Bethard :
There is an undocumented value for add_argument's nargs parameter, REMAINDER,
which can be used to consume all the remaining arguments. This is commonly
useful for command line utilities that dispatch to other command line utilities.
Though undocum
Steven Bethard added the comment:
Looks good. A few minor comments (click "review" by the patch).
--
___
Python tracker
<http://bugs.python.o
Steven Bethard added the comment:
I agree this is a bug. The patch needs to add unit tests that make sure
metavars with [] work as expected.
--
___
Python tracker
<http://bugs.python.org/issue11
Steven Bethard added the comment:
I think Issue 12776, which delays type conversions on defaults, should solve
this problem, right? If you agree, could you add your code here as a test case
to that issue and mark this as duplicate?
--
___
Python
Steven Bethard added the comment:
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue9938>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steven Bethard added the comment:
%(prog)s is available in epilog:
-- temp.py --
import argparse
epilog = """\
Example usage:
%(prog)s option1 option2
"""
parser = argparse.ArgumentParser(
formatter_class=argparse.RawTextHe
Steven Bethard added the comment:
I agree that this is a bug in current argparse formatting.
It might be a little difficult to fix though because the current option
formatting handles arguments one at a time, and producing something like [arg1
[arg2]] requires some understanding of how
Steven Bethard added the comment:
Could you give some examples of bugs that you observed? Otherwise, this looks
like a duplicate of issue 9349.
The intention is that help=SUPPRESS should cause the given argument to not be
displayed in the help message. If there are cases where that'
Steven Bethard added the comment:
Modulo the comments already on the patch by others, this approach looks fine to
me.
--
___
Python tracker
<http://bugs.python.org/issue12
Steven Bethard added the comment:
Your solution is actually the current recommended solution - mix together both
classes that you want to combine and pass your subclass as the parameter. This
should probably be documented somewhere (and tested more
Steven Bethard added the comment:
If you can make your patch relative to the cpython source tree, and add a
couple tests, it will be easier to review.
Thanks for working on this!
--
___
Python tracker
<http://bugs.python.org/issue9
Steven Bethard added the comment:
As I understand it the current proposal is:
* Wrap each paragraph separately
* Don't wrap any lines indented by at least one additional space
This sounds like a useful formatter. I would probably call it
"PargraphWrappingFormatter" or some
Steven Bethard added the comment:
I'd feel more comfortable with the argparse fix if it were simply calling
"os.get_terminal_size()". I recommend that you:
* Create a new issue called, say "add os.get_terminal_size()" proposing just
the single method.
* Add that iss
Steven Bethard added the comment:
I think http://bugs.python.org/issue12776, which delays type conversions on
defaults should solve this problem, right? If you agree, could you add your
code here as a test case to that issue and mark this as duplicate?
(And yes, I agree this is a bug
Steven Bethard added the comment:
The ArgumentParser constructor is definitely only intended to be called with
keyword arguments, so it's definitely a documentation bug that it doesn't say
this. I haven't actually applied the patch, but the basic approach and wording
Steven Bethard added the comment:
Looks good to me too.
--
___
Python tracker
<http://bugs.python.org/issue10772>
___
___
Python-bugs-list mailing list
Unsub
Steven Bethard added the comment:
Could you add a test to verify that custom actions are still getting the
converted values passed to their __call__? I suspect this may not be happening
under the current patch - if that's the case, you may also need to add
conversions in _get_values,
1 - 100 of 303 matches
Mail list logo
