Steven Bethard steven.beth...@gmail.com added the comment:
Looks good. A few minor comments (click review by the patch).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11807
New submission from Steven Bethard steven.beth...@gmail.com:
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
Changes by Steven Bethard steven.beth...@gmail.com:
--
assignee: - bethard
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Steven Bethard steven.beth...@gmail.com added the comment:
Sorry for letting this bug sit around for so long. I committed a slight variant
of your patch to 2.7, 3.2 and 3.3. Thanks!
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
versions: +Python
Steven Bethard steven.beth...@gmail.com added the comment:
The problem still exists in current trunk:
The slicing semantics have been removed from the expressions reference:
http://docs.python.org/py3k/reference/expressions.html#slicings
The datamodel and types sections still have the same
Changes by Steven Bethard steven.beth...@gmail.com:
--
stage: test needed - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1446619
New submission from Steven Bethard steven.beth...@gmail.com:
I'm going to try to merge several closely related issues here. Basically,
people would like better control over the usage message formatting so that you
could:
* Put program name and version information at the top of the message
Steven Bethard steven.beth...@gmail.com added the comment:
I'm moving this over to Issue 11695, which proposes support for a usage/help
message template.
--
resolution: - duplicate
stage: - committed/rejected
status: open - closed
superseder: - Improve argparse usage/help
Steven Bethard steven.beth...@gmail.com added the comment:
I'm moving this over to Issue 11695, which proposes support for a usage/help
message template.
To customize the argument group names, the recommended approach is to create
your own argument groups, and only put arguments there, e.g
Steven Bethard steven.beth...@gmail.com added the comment:
So it strikes me that there already exists an officially supported way to
rename your option groups. Just only create your own option groups (never use
the default ones) and only put arguments there, e.g
Steven Bethard steven.beth...@gmail.com added the comment:
I'm moving this over to Issue 11695, which proposes support for a usage/help
message template.
--
resolution: - duplicate
stage: - committed/rejected
status: open - closed
superseder: - Improve argparse usage/help
Steven Bethard steven.beth...@gmail.com added the comment:
Thanks for the analysis Eric. Yeah, it does seem like it's not possible to
implement this feature request while still supporting optionals with variable
number arguments.
@andersk: Would the restriction to only having flags
Steven Bethard steven.beth...@gmail.com added the comment:
In argparse, you could so something like:
version = 2.7
parser = argparse.ArgumentParser(
description=My program XXX, version + version)
parser.add_argument('-v', action='version', version=version)
That would then produce:
usage
Steven Bethard steven.beth...@gmail.com added the comment:
Sorry about such a slow response on this. Thanks for the patch!
I think rather than adding an ArgumentParser constructor parameter though, we
should add a new formatter class. The attached patch allows you to write:
parser
Steven Bethard steven.beth...@gmail.com added the comment:
I'm not sure about the usage_template approach - seems like it might be hard to
make it work, while still supporting formatter_class. (Though maybe it's not so
bad since the formatter class methods are all considered implementation
Changes by Steven Bethard steven.beth...@gmail.com:
--
assignee: - bethard
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11174
Steven Bethard steven.beth...@gmail.com added the comment:
Thanks for the patch. The idea and the approach of the patch look fine. But the
patch needs to be against the Python repository:
http://docs.python.org/devguide/patch.html#creating
For the tests, you should integrate your test.py
Steven Bethard steven.beth...@gmail.com added the comment:
I think this is a great suggestion. Care to work on a patch?
--
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11588
Changes by Steven Bethard steven.beth...@gmail.com:
--
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10680
Steven Bethard steven.beth...@gmail.com added the comment:
Thanks for the patch. I used something similar to what you proposed, but
instead of creating a local formatter, I just call self._get_formatter() if it
exists.
--
assignee: - bethard
nosy: -python-dev
resolution: - fixed
Steven Bethard steven.beth...@gmail.com added the comment:
I fixed the docs here so that they're clearer about what the Namespace object
is, and also so that they mention the `vars` approach if you want dict-style
access.
--
resolution: - fixed
stage: needs patch - committed/rejected
Steven Bethard steven.beth...@gmail.com added the comment:
I added some documentation in the parents section of the argparse docs.
--
assignee: docs@python - bethard
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python
Steven Bethard steven.beth...@gmail.com added the comment:
There's no argparse in 3.1, so it should only go into 2.7, 3.2 and 3.3. But
yes, the patch looks great to me too.
--
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
http
Steven Bethard steven.beth...@gmail.com added the comment:
The request was for the latter: just make it stronger in the mentioned line
that what was called previously 'option' is now called 'args'.
As far as adding the parentheses or not, I never once used the parentheses back
when I
Steven Bethard steven.beth...@gmail.com added the comment:
Looks good to me. This is a doc fix, so it could go into 3.2 and 2.7 as well as
3.3.
--
versions: +Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Steven Bethard steven.beth...@gmail.com added the comment:
Crashing on an empty line is definitely a bug.
Each line being a single option is documented behavior:
http://docs.python.org/dev/library/argparse.html#fromfile-prefix-chars
--
nosy: +bethard
New submission from Steven Bethard steven.beth...@gmail.com:
Suggestion from a personal email:
I generally like my command line arguments that take a
value to specify the type, e.g.,
--runs int how many runs to do
Naturally I can do this using the metavars argument in every
New submission from Steven Bethard steven.beth...@gmail.com:
Suggestion from a personal email:
Allow FileType to accept encoding and errors arguments
and pass these as keyword arguments to codecs.open() instead of open().
--
components: Library (Lib)
messages: 128301
nosy: bethard
New submission from Steven Bethard steven.beth...@gmail.com:
Suggestion from a personal email:
I personally am not keen on the foo/bar/baz examples. I
know that you're trying to be generic but IMO it would be much easier to
understand if you used meaningful names. Also, I think that the very
Steven Bethard steven.beth...@gmail.com added the comment:
Probably because the suggestion came from someone thinking about both Python 2
and 3. But given that this feature request can only target Python 3.3, you're
absolutely right that there's no need to go through the codecs module
Steven Bethard steven.beth...@gmail.com added the comment:
Maybe dont_assume_everything_that_looks_like_a_flag_is_intended_to_be_one
should actually be a new class, e.g.
parser = AllowFlagsAsPositionalArgumentsArgumentParser()
Then you just wouldn't provide parse_known_args on that parser
Steven Bethard steven.beth...@gmail.com added the comment:
Argparse's wrapping behavior is determined by the formatter_class:
http://docs.python.org/library/argparse.html#formatter-class
Is it reasonable to assume that if you're wrapping your own messages you're
already specifying
Steven Bethard steven.beth...@gmail.com added the comment:
Yes, definitely `vars` deserves some description and an example in the
documentation. This isn't the first time this question has come up. =)
--
___
Python tracker rep...@bugs.python.org
Steven Bethard steven.beth...@gmail.com added the comment:
Yeah, I agree it's not ideal, though note that basic unix commands have trouble
with arguments staring with dashes:
$ cd -links-/
-bash: cd: -l: invalid option
cd: usage: cd [-L|-P] [dir]
If you're working with a file on a filesystem
Steven Bethard steven.beth...@gmail.com added the comment:
I don't think there's any sense in un-deprecating optparse because:
(1) It's only deprecated in the documentation - there is absolutely nothing in
the code to keep you from continuing to use it, and there are no plans to
remove
Steven Bethard steven.beth...@gmail.com added the comment:
@Éric: yes, thanks!
@Anders: The reason the current implementation gives you the behavior you don't
want is that the first thing it does is scan the args list for things that look
like flags (based on prefix_chars). It assumes
Steven Bethard steven.beth...@gmail.com added the comment:
What's wrong with `vars(args)`? That's the standard way of getting a dict from
an object, no?
Note that you're not always guaranteed to get a Namespace back (e.g. if you
pass the namespace= argument to parse_args), and I'd generally
Steven Bethard steven.beth...@gmail.com added the comment:
Looks great, thanks. I've updated the patch so it applies okay to both
release27-maint and py3k. All tests pass on both branches.
It's a one line fix and the test case looks good, so there should be no problem
applying
Changes by Steven Bethard steven.beth...@gmail.com:
Removed file: http://bugs.python.org/file20548/issue10680_withTestcase.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10680
Changes by Steven Bethard steven.beth...@gmail.com:
Removed file: http://bugs.python.org/file20114/argparse.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10680
Steven Bethard steven.beth...@gmail.com added the comment:
Awesome, thanks! Do you want to apply to 2.7 or should I?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10680
Steven Bethard steven.beth...@gmail.com added the comment:
Done in r88268. Thanks again everyone!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10680
Steven Bethard steven.beth...@gmail.com added the comment:
It's an ArgumentTypeError because that's what you're supposed to raise inside
type functions:
http://docs.python.org/dev/library/argparse.html#type
(Note that argparse.FileType.__call__ is what will be called when we pass
type
Steven Bethard steven.beth...@gmail.com added the comment:
Fixed in r88169 and r88171. Thanks everyone for your help! I'll be keeping my
eye on the buildbots for a bit to make sure everything stays green.
--
assignee: - bethard
resolution: - fixed
stage: patch review - committed
Steven Bethard steven.beth...@gmail.com added the comment:
I'm definitely open to providing such functionality. I assume you're imagining
something like:
parser = argparse.ArgumentParser()
a_action = parser.add_argument('-a')
b_action = parser.add_argument('-b')
c_action = parser.add_argument
Steven Bethard steven.beth...@gmail.com added the comment:
Georg, is this something we can patch for rc2? It's a bug - errors encountered
by argparse-internal code should be translated into command line errors, and
they currently aren't for read-only files.
For what it's worth, the tests fail
Steven Bethard steven.beth...@gmail.com added the comment:
Good point. Here's the updated patch that reports the IOError as well. All
tests pass. I'll apply in a bit if I don't hear otherwise.
--
Added file: http://bugs.python.org/file20491/argparse.diff
Steven Bethard steven.beth...@gmail.com added the comment:
The docs for os.chmod claim:
Availability: Unix, Windows.
Although Windows supports chmod(), you can only set the file's read-only flag
with it (via the stat.S_IWRITE and stat.S_IREAD constants or a corresponding
integer value). All
Steven Bethard steven.beth...@gmail.com added the comment:
action=help definitely needs to be documented
action=count probably should be, though I think it's pretty useless (I just
copied it from optparse)
action=parsers, nargs=... and nargs=A... I'm not so sure about. These are
currently
Changes by Steven Bethard steven.beth...@gmail.com:
--
stage: needs patch - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9355
Steven Bethard steven.beth...@gmail.com added the comment:
Yep, I believe that fix should work. Now to find the time to write some tests...
--
nosy: +bethard
stage: - unit test needed
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
Steven Bethard steven.beth...@gmail.com added the comment:
Looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9234
___
___
Python
Steven Bethard steven.beth...@gmail.com added the comment:
Yep, this is a documentation bug. Help is definitely intended to print to
stdout.
--
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10728
Steven Bethard steven.beth...@gmail.com added the comment:
Applied in r87362.
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9234
Steven Bethard steven.beth...@gmail.com added the comment:
The patch looks basically okay to me, though this line makes me nervous:
dest += ' (%s)' % ', '.join(aliases)
Since this is just for help formatting, can't you just modify metavar instead?
The dest is the attribute on the namespace
Steven Bethard steven.beth...@gmail.com added the comment:
In the short term, just catch the SystemExit.
In the slightly longer term, we could certainly provide a subclass, say,
ErrorRaisingArgumentParser, that overrides .exit and .error to do nothing but
raise an exception with the message
Steven Bethard steven.beth...@gmail.com added the comment:
The workaround in TestImportStar is fine. The test is really just meant to make
sure that __all__ contains all the current API methods, and the _ checks were
the easiest way at the time to check
Steven Bethard steven.beth...@gmail.com added the comment:
If I understand it right, before this patch, people couldn't really supply
internationalizations for these calls - they would have had to have a
translation for each possible value of, e.g. action.choices or
parser.prefix_chars. So I
Steven Bethard steven.beth...@gmail.com added the comment:
Hmm. I see I confused this with Issue 10529, where there really was a bug in
the gettext calls. Nonetheless, +1 for switching from %s to %(xxx)s in 3.2 -
since that's the first release in Python 3 that has argparse, I think it's
Steven Bethard steven.beth...@gmail.com added the comment:
Yes, I think it's okay to fix this without a test, given that it's a nontrivial
amount of work to test gettext stuff. I'd rather have it working now, without
tests, than wait until we know how to test stuff with gettext.
It's also
Steven Bethard steven.beth...@gmail.com added the comment:
With argparse, you can specify formatter_class= RawDescriptionHelpFormatter and
then format things however you want in the description.
http://docs.python.org/dev/library/argparse.html#formatter-class
So I think there's no need
Steven Bethard steven.beth...@gmail.com added the comment:
Tried to comment in Rietveld but it didn't work for some reason. Anyway, I
think the argparse.py patch isn't good - changing the type error message to
'invalid %s value: %r details: %s' will change the behavior of a bunch of
programs
Steven Bethard steven.beth...@gmail.com added the comment:
Sorry, I was looking at the akira patch with the same date, where I was mainly
worried about the modification of the except (TypeError, ValueError): block.
Your patch doesn't do that, and looks fine
Steven Bethard steven.beth...@gmail.com added the comment:
I think it's fine to fix this in 3.2 by switching to mappings where necessary.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10528
Steven Bethard steven.beth...@gmail.com added the comment:
I'm not sure about the patch - this will convert *all* IOErrors into command
line error messages, while we should really only be converting the ones raised
by FileType. Instead, the try/except should be in FileType.__call__, and you
Steven Bethard steven.beth...@gmail.com added the comment:
Looks like a great fix.
And yes, anyone who knows anything about gettext, please feel free to add a
test or ten. ;-) I just copied optparse when I put that stuff in, so I have no
confidence in how it's done now
Steven Bethard steven.beth...@gmail.com added the comment:
Yeah, sorry, those last two should have had arguments after them.
I think we have to stick with the current behavior - otherwise there's no way
to do something like -x -A -B, where you want -A and -B to be arguments to -x.
(You can
Steven Bethard steven.beth...@gmail.com added the comment:
Yeah a new test class is fine.
And I checked the patch and it looks okay to me. My first thought was also
wait does that really work? but I see that positionals are all marked as
required when appropriate (look for the comment
Steven Bethard steven.beth...@gmail.com added the comment:
Sorry, I think I confused you, please post that patch here. This issue is for
documenting the workarounds, issue 9338 is for actually solving the problem.
I glanced at your patch on that issue, and it looks basically okay, though I'd
Steven Bethard steven.beth...@gmail.com added the comment:
No, it's exactly line 1925 that's the problem. The OP would like that to tell
him which arguments were missing instead of saying just 'too few arguments'.
The block below that is for checking required optionals/positionals. It won't
Steven Bethard steven.beth...@gmail.com added the comment:
The original point is basically a duplicate of issue 9338. It is undesirable
behavior, I just don't know how to fix it. Patches to fix it are welcome (on
issue 9338). ;-)
As to documenting '--', I agree it's hidden too far down
Steven Bethard steven.beth...@gmail.com added the comment:
I think the proposed API looks fine and should be backwards compatible since
add_subparsers will currently throw an exception with a default= argument.
In case someone feels like writing a patch, you'll want to look
New submission from Steven Bethard steven.beth...@gmail.com:
From a personal email:
--
I'm not signed up for all the Python issue tracking stuff, but thought I'd let
you know about a problem with the argparse doc page
New submission from Steven Bethard steven.beth...@gmail.com:
From a private email in respect to the following class of error messages:
parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument('--foo')
parser.add_argument('--bar')
parser.add_argument('ham')
parser.add_argument
Steven Bethard steven.beth...@gmail.com added the comment:
Yep, argparse almost certainly has the same kind of problems - I basically
copied the optparse gettext behavior into argparse because I don't really know
how that stuff works but figured people must have wanted what
Steven Bethard steven.beth...@gmail.com added the comment:
Fixed with a variant of Catherine's patch (following R. David Murray's
suggestion of inlining the two methods) in r86111 (3.X) and r86112 (2.7). Also
added one more test to make sure that the order of the extra arguments is
consistent
Steven Bethard steven.beth...@gmail.com added the comment:
Fixed with a variant of Denver's last patch in r86080 for 3.X and r86083 for
2.7.
--
assignee: - bethard
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
Steven Bethard steven.beth...@gmail.com added the comment:
Fixed in 3.X in r86086 and in 2.7 in r86087.
--
assignee: - bethard
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9353
Changes by Steven Bethard steven.beth...@gmail.com:
--
nosy: -bethard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4640
___
___
Python-bugs-list
Steven Bethard steven.beth...@gmail.com added the comment:
Patches applied in r86090 (3.X) and r86091 (2.7). Thanks for your help
Catherine, and sorry it took me so long to apply these.
--
assignee: - bethard
resolution: - fixed
status: open - closed
Steven Bethard steven.beth...@gmail.com added the comment:
Committed in r86092 (3.X) and r86093 (2.7). Thanks for the patches!
--
assignee: - bethard
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Steven Bethard steven.beth...@gmail.com added the comment:
Closing as invalid, as to me this looks like a classic terminal encoding issue
and not an argparse issue, and there was no response from the user who filed
the issue. If someone still thinks this is an argparse issue, please provide
Steven Bethard steven.beth...@gmail.com added the comment:
Could you elaborate a little on what you use it for? The argparse module only
uses this for pretty __repr__ on the various objects. (And in fact, it looks
like it's gotten a little out of sync - required is missing from Action
Steven Bethard steven.beth...@gmail.com added the comment:
Would you have to do this for every installed distribution?
Seems cumbersome.
Well, the feature not being implemented yet, it's hard to tell what it would
do. ;-) But I think the simplest approach would actually yield a dialog where
Changes by Steven Bethard steven.beth...@gmail.com:
--
nosy: +bethard
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9938
Steven Bethard steven.beth...@gmail.com added the comment:
Are you sure this is an argparse issue, and not a terminal issue? Here's what I
see:
parser = argparse.ArgumentParser(description=u'Rus Рус')
print(parser.description)
Rus Рус
sys.stderr.write(parser.description)
Traceback (most
Steven Bethard steven.beth...@gmail.com added the comment:
I think this is still really a feature request. We can't just change the text
from optional - that would silently change a large number of help messages
without any warning. So to fix this bug, we're going to have to add an API
Steven Bethard steven.beth...@gmail.com added the comment:
I guess one possibility might be flag arguments. It's not great, but I guess
it's more accurate.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9694
Steven Bethard steven.beth...@gmail.com added the comment:
And I guess the bigger issue to think about is how to add this in a backwards
compatible way. I guess we could just add methods like
set_positionals_group_name(name) and then fiddle with
self._positionals.title in there. Not sure
Steven Bethard steven.beth...@gmail.com added the comment:
Looks like usage is almost always lowercase in the programs I tried (ssh,
svn, cat, etc.). So it probably wouldn't be a good idea to change the default.
Seems like both this and issue 9694 need a better way to customize the text
Steven Bethard steven.beth...@gmail.com added the comment:
Yeah, I guess the optional vs. positional isn't the best terminology now that
you can have required flag-based arguments. Did you have a word other than
optional that you'd prefer
Steven Bethard steven.beth...@gmail.com added the comment:
I see. When there are no arguments you basically want to replace the standard
argparse help entirely with your own message, with your own capitalization,
etc. What you're doing now looks like a pretty good approach for this, so I
Steven Bethard steven.beth...@gmail.com added the comment:
A simpler approach might be to do this before your call to parse_args:
if len(sys.argv[0]) == 1:
parser.print_help()
Does that solve your problem?
--
___
Python tracker rep
Steven Bethard steven.beth...@gmail.com added the comment:
Sorry, typo. Should have been len(sys.argv) == 1. Full script:
import argparse
import sys
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
if len(sys.argv) == 1:
parser.print_help()
else:
print
Changes by Steven Bethard steven.beth...@gmail.com:
--
nosy: +bethard
stage: - needs patch
versions: +Python 2.7, Python 3.2 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9625
Steven Bethard steven.beth...@gmail.com added the comment:
This is closely related to issue 9338. The parser should know that your command
line requires at least the COMMAND argument, so it should stop parsing in time
for that. However, in the case of subcommands, even if we solved issue 9338
Steven Bethard steven.beth...@gmail.com added the comment:
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).
I do believe that supporting
Steven Bethard steven.beth...@gmail.com added the comment:
These all look like good changes to me. (I looked at the patch, but haven't
tried applying it though.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9554
Steven Bethard steven.beth...@gmail.com added the comment:
Marking as duplicate of 9553 (which has a better description and a patch).
--
resolution: - duplicate
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9345
Steven Bethard steven.beth...@gmail.com added the comment:
The best solution would be to make sure that a few different column widths are
tested. However, in the meantime, the tests do assume 80 columns, so I think
it's correct to specify that using os.environ as suggested.
One problem
101 - 200 of 1712 matches
Mail list logo
