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 help=SUPPRESS
Steven Bethard added the comment:
Looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15935
___
___
Python-bugs-list mailing list
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
incompatible
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
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 rep...@bugs.python.org
http://bugs.python.org/issue15929
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 rep...@bugs.python.org
http
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 returns
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 rep...@bugs.python.org
http://bugs.python.org/issue15906
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:
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
current behavior is essentially
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:
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.
--
___
Python
Changes by Steven Bethard steven.beth...@gmail.com:
--
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15832
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
___
Python tracker
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 since
Changes by Steven Bethard steven.beth...@gmail.com:
--
resolution: - duplicate
superseder: - argparse optionals with nargs='+' can't be followed by
positionals
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15433
Changes by Steven Bethard steven.beth...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15433
___
___
Python
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com added the comment:
And I guess Issue 9182 is the right place for (1).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9338
Steven Bethard steven.beth...@gmail.com 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 section
Steven Bethard steven.beth...@gmail.com 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 rep...@bugs.python.org
http
Steven Bethard steven.beth...@gmail.com 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 implementation
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
New submission from Steven Bethard steven.beth...@gmail.com:
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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 to the
attribute
Steven Bethard steven.beth...@gmail.com 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
arguments
Steven Bethard steven.beth...@gmail.com 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 great
Changes by Steven Bethard steven.beth...@gmail.com:
--
resolution: - duplicate
status: open - closed
superseder: - argparse: Default Help Message Lists Required Args As Optional
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
New submission from Steven Bethard steven.beth...@gmail.com:
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
Steven Bethard steven.beth...@gmail.com 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 rep...@bugs.python.org
http
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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.patch
Steven Bethard steven.beth...@gmail.com added the comment:
This patch looks like the right fix to me. The tests look good too.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13922
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 steven.beth...@gmail.com 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't distinguish between
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 steven.beth...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org
Steven Bethard steven.beth...@gmail.com 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 steven.beth...@gmail.com 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 rep
Changes by Steven Bethard steven.beth...@gmail.com:
--
resolution: - duplicate
status: open - closed
superseder: - argparse: Default Help Message Lists Required Args As Optional
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org
Steven Bethard steven.beth...@gmail.com 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 -I and --ignore
Steven Bethard steven.beth...@gmail.com 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 just say again
Steven Bethard steven.beth...@gmail.com added the comment:
Yep. Closing as duplicate.
--
resolution: - duplicate
status: open - closed
superseder: - argparse: allow abbreviation of sub commands by users
___
Python tracker rep...@bugs.python.org
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 rep...@bugs.python.org
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 messages and
foo_bar
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com added the comment:
Yes, the problem is in FileType.__call__ - the handling of '-' is pretty
simplistic. Patches welcome.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14156
Steven Bethard steven.beth...@gmail.com 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 rep
Steven Bethard steven.beth...@gmail.com 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!
--
___
Python tracker rep
Steven Bethard steven.beth...@gmail.com added the comment:
It's undocumented, and it begins with an underscore, but it would certainly be
safer to deprecate it first.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14075
Steven Bethard steven.beth...@gmail.com added the comment:
I think adding a new formatter for man pages would be generally useful.
Assuming someone provides a patch. ;-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14102
Steven Bethard steven.beth...@gmail.com 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 steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com added the comment:
Oh ok. Sounds good then!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14034
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 anymore
Steven Bethard steven.beth...@gmail.com added the comment:
The implementation looks along the right track. Now it just needs some tests.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9253
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com added the comment:
The idea and patch seem okay to me. Needs tests though.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13966
Steven Bethard steven.beth...@gmail.com 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 rep
Steven Bethard steven.beth...@gmail.com added the comment:
Sounds like an excellent plan to me too.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13850
Steven Bethard steven.beth...@gmail.com added the comment:
Eric's suggested doc fix looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13685
Steven Bethard steven.beth...@gmail.com added the comment:
Closing then. Thanks for checking it again!
--
assignee: - bethard
resolution: - works for me
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Steven Bethard steven.beth...@gmail.com added the comment:
Sorry about being out of contact (I'm flying back and forth between the US and
the EU every 4-5 weeks right now), and thanks Terry for bringing this to my
attention.
Essentially, the API is:
* The argument to action= must
Steven Bethard steven.beth...@gmail.com added the comment:
Can you submit some example code that shows this? I can't reproduce this with:
-- temp.py --
import argparse
parser = argparse.ArgumentParser()
parser.add_argument(--ng, action=store_true)
parser.add_argument(--INP
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com added the comment:
Looks good to me too.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10772
Steven Bethard steven.beth...@gmail.com 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 steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 issue
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 rep...@bugs.python.org
Steven Bethard steven.beth...@gmail.com 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 steven.beth...@gmail.com added the comment:
Modulo the comments already on the patch by others, this approach looks fine to
me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12713
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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.RawTextHelpFormatter,
epilog=epilog
Steven Bethard steven.beth...@gmail.com added the comment:
Looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9938
___
___
Python
Steven Bethard steven.beth...@gmail.com 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
Steven Bethard steven.beth...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue11874
1 - 100 of 1712 matches
Mail list logo
