Steven Bethard 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
Steven Bethard 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.des
Changes by Steven Bethard :
--
nosy: +bethard
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue9938>
___
___
Python-bugs-list mailin
Steven Bethard 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
you simpl
Steven Bethard 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, and
a numbe
Steven Bethard 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
<http://bugs.pyt
Steven Bethard added the comment:
Fixed in 3.X in r86086 and in 2.7 in r86087.
--
assignee: -> bethard
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Steven Bethard :
--
nosy: -bethard
___
Python tracker
<http://bugs.python.org/issue4640>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steven Bethard 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 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
<http://bugs.python.o
Steven Bethard 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 a
test and reopen the
Steven Bethard 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 (extra argu
Steven Bethard 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 was in
New submission from Steven Bethard :
>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:
http://do
New submission from Steven Bethard :
>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')
Steven Bethard 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 at
_SubParsersAction.__init__, which
Steven Bethard 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 with a fixed number of
argu
Steven Bethard 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
Steven Bethard 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 = argparse.Argum
Steven Bethard 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
details.) I
Changes by Steven Bethard :
--
assignee: -> bethard
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Steven Bethard 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 into Lib/test
Steven Bethard added the comment:
I think this is a great suggestion. Care to work on a patch?
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issu
Changes by Steven Bethard :
--
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10680>
___
__
Steven Bethard 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
stage: needs
Steven Bethard 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
s
Steven Bethard 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
___
Steven Bethard 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: +P
Steven Bethard 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 equations:
http
Changes by Steven Bethard :
--
stage: test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue1446619>
___
___
Python-bugs-list mai
New submission from Steven Bethard :
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
* Customize the &
Steven Bethard 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/h
Steven Bethard 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.:
p
Steven Bethard 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.:
- temp.py
Steven Bethard 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/h
Changes by Steven Bethard :
--
assignee: -> bethard
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.3
___
Python tracker
<http://bugs.pytho
Steven Bethard 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 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 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 starting
Steven Bethard 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
like to see a few
Steven Bethard 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 get that now with -x
Steven Bethard 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
should rai
Steven Bethard 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 don
Steven Bethard added the comment:
I think it's fine to fix this in 3.2 by switching to mappings where necessary.
--
___
Python tracker
<http://bugs.python.org/is
Steven Bethard 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 behavi
Steven Bethard 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,
Steven Bethard 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 for this in arg
Steven Bethard 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 think there
Steven Bethard 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
really okay
Steven Bethard 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 a prett
Changes by Steven Youngs :
--
nosy: +StevenY
___
Python tracker
<http://bugs.python.org/issue10363>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steven D'Aprano added the comment:
It seems to me that an explicit raise inside an except block should *not* chain
exceptions by default. The rationale for chaining exceptions is to detect bugs
in the exception handler:
try:
something
except SomeError:
y = 1/x # oops, what ha
Steven Bethard 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
Steven Bethard 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 namespac
Steven Bethard 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 they would have printed
Steven Bethard added the comment:
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue9234>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steven Bethard added the comment:
Yep, this is a documentation bug. Help is definitely intended to print to
stdout.
--
versions: -Python 3.1
___
Python tracker
<http://bugs.python.org/issue10
Steven Bethard added the comment:
Applied in r87362.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Steven Bethard :
--
stage: needs patch -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue9355>
___
___
Python-bugs-list mai
Steven Bethard 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
<http://bugs.python.org/issu
Steven Bethard 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...&qu
Steven Bethard 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 = pars
Steven Bethard 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 fa
Steven Bethard 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 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 other bits are ig
Steven Bethard 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/r
Steven Bethard 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=argparse.F
Steven Bethard 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 this to release27-maint.
Fo
Changes by Steven Bethard :
Removed file: http://bugs.python.org/file20548/issue10680_withTestcase.patch
___
Python tracker
<http://bugs.python.org/issue10680>
___
___
Changes by Steven Bethard :
Removed file: http://bugs.python.org/file20114/argparse.diff
___
Python tracker
<http://bugs.python.org/issue10680>
___
___
Python-bugs-list m
Steven Bethard added the comment:
Awesome, thanks! Do you want to apply to 2.7 or should I?
--
___
Python tracker
<http://bugs.python.org/issue10680>
___
___
Steven Bethard added the comment:
Done in r88268. Thanks again everyone!
--
___
Python tracker
<http://bugs.python.org/issue10680>
___
___
Python-bugs-list mailin
Steven Bethard 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 lik
Steven Bethard 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
<http://bugs.python.org/is
Steven Bethard 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, the ti
Steven Bethard 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 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 that everything that looks
Steven Bethard 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 p
Steven Bethard 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 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
___
Python tracker
New submission from Steven Bethard :
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
add_argument() call, but that can
New submission from Steven Bethard :
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
priority: low
severity
New submission from Steven Bethard :
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
first example you
Steven Bethard 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 cod
Steven Bethard 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
<http://bugs.python.org/is
Steven Bethard 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
wh
Steven Bethard 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
<http://bugs.python.org/issue10
New submission from Steven Wong <[EMAIL PROTECTED]>:
Communicating over HTTPS at the default port of 443:
import httplib
conn = httplib.HTTPSConnection("my-secure-domain.com")
conn.request("GET", "/")
res = conn.getresponse()
In the current implementation,
Steven Wong <[EMAIL PROTECTED]> added the comment:
Clarification: I am not saying that sending "Host: somehost:443" for an
HTTPS connection at port 443 is a bug. It is in fact legal. Sending
"Host: somehost" is also legal in this situation, and IMHO is the
preferred be
New submission from Steven Hartland :
When using SimpleXMLRPCServer that is used to return data that includes strings
that have a \x00 in them this data is returned, which is invalid.
The expected result is that the data should be treated as binary and base64
encoded.
The bug appears to be
Steven Hartland added the comment:
One thing that springs to mind is how valid is that when applied to utf8 data?
--
___
Python tracker
<http://bugs.python.org/issue7
New submission from Steven D'Aprano :
There is a command line switch -U (uppercase U) which is mentioned in PEP 3147
http://www.python.org/dev/peps/pep-3147/ but doesn't appear to be documented
anywhere.
It is listed here, but not described:
http://docs.python.org/using/cmdline
Steven D'Aprano added the comment:
If the switch is intentionally not documented, perhaps it should be removed
from here:
http://docs.python.org/using/cmdline.html#command-line
where it is listed but not explained anywhere. As it stands now, the
*existence* of the switch is documented
Steven D'Aprano added the comment:
The patch you suggest is *not* sufficient, at least not by my testing.
However, the attached patch does work, according to my tests.
--
nosy: +stevenjd
Added file: http://bugs.python.org/file16158/patch
___
P
Steven D'Aprano added the comment:
Attached is a simple test script for the patch I submitted. I have tested it
with Python 2.6 both before and after applying the patch. Run it from the
command line.
With the unpatched doctest module, it prints:
"Expected 2 doctests, but on
New submission from steven Michalske :
I started using the .format() on strings and was surprised that it was lacking
an built in format specifier for engineering notation.
For those unfamiliar with engineering notation it puts the exponent of the
number in modulo 3 so that it is in alignment
New submission from steven Michalske :
It is a common practice to separate hex digits with a "thousands" separator
every 4 hex digits.
0x1234_abcd
Although python does not accept the _ as a thousands separator in hex notation,
neither is the thousands separator in base 10
Sn
steven Michalske added the comment:
I'll work on a proposal for the ideas list.
Other language examples to keep this in a thread though.
perl -e 'print 0x1234_abcd; print "\n";'
C/C++ seems to not support the underscore.
Lua unsupported.
Data sheets from micro cont
steven Michalske added the comment:
Sorry my request is for output, I am not requesting input. The examples were
for showing the use in other contexts of using an underscore as a word (4 hex
digits) seperaror.
My assertions are from another area aside from computer languages, but from
New submission from Steven D'Aprano :
String interpolation % operates on unicode strings directly without calling the
__str__ method. In Python 2.5 and 2.6:
>>> class K(unicode):
... def __str__(self): return "Surprise!"
...
>>> u"%s" % K("so
101 - 200 of 1942 matches
Mail list logo
