paul j3 added the comment:
This patch removes only one '--', the one that put a '-' in the
'arg_strings_pattern'. It does this in 'consume_positionals' right before
calling 'take_action'. As before it does not do this if nargs
paul j3 added the comment:
This patch permits the mixing of optionals with positionals, with the caveat
that a particular positional cannot be split up.
If:
parser = ArgumentParser()
parser.add_argument('-f','--foo')
parser.add_argument('cmd')
par
paul j3 added the comment:
It does shift the error from parse_args to add_argument, but the message
'ValueError: length of metavar tuple does not match nargs', indicates that it's
a side effect of checking on the tuple form of `metavar`.
http://bugs.python.org/issue9348
Ther
paul j3 added the comment:
I've experimented with an argparse adaptation of profile.py:
parser = argparse.ArgumentParser(usage=usage)
parser.add_argument('-o', '--outfile', dest="outfile",
help="Save stats to ", metavar="path&qu
paul j3 added the comment:
In this example:
>>> p.add_argument('--foo', nargs='*', default=None)
>>> p.parse_args([])
Namespace(foo=None)
>>> p.parse_args(['--foo'])
Namespace(foo=[])
'p.parse_args([])'
paul j3 added the comment:
The problem isn't with REMAINDER, but with the distinction between optionals
and arguments. If you change '--def' to 'def', the parse should work:
>>> p = ArgumentParser(prog='test.py')
>>> p.add_argument('re
paul j3 added the comment:
Here's a way of passing an optional-like argument to a subparser:
parser = argparse.ArgumentParser()
subparsers = parser.add_subparsers(dest='cmd')
sub1 = subparsers.add_parser('cmd')
sub1.add_argument('foo',nargs=&#x
Changes by Paul Winkler :
--
nosy: +slinkp
___
Python tracker
<http://bugs.python.org/issue13831>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Paul Winkler :
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue13831>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
An alternative to Jason's example:
parser = argparse.ArgumentParser()
parser.add_argument('app')
parser.add_argument('--config')
parser.add_argument('app_args', nargs=argparse.REMAINDER)
args = parser.parse_args(['--confi
paul j3 added the comment:
By the way, parser.parse_args() uses parse_known_arg(). parse_known_args
returns a Namespace and a list of unknown arguments. If that list is empty,
parse_args returns the Namespace. If the list is not empty, parse_args raises
an error.
So parse_known_args does
paul j3 added the comment:
parser = argparse.ArgumentParser()
parser.add_argument('-k','--known',action='store_true')
print(parser.parse_known_args(['-k','-u']))
print(parser.parse_known_args(['-ku']))
print(parser.p
paul j3 added the comment:
The 'subparsers' object has a _parser_class attribute that is normally set to
the class of the parent parser. In the attached file I create a
class CustomParser(argparse.ArgumentParser)
that makes a parser instance which copies all of the att
paul j3 added the comment:
Glenn
Take a look at http://bugs.python.org/issue15427
I took a stab at changing the documentation, including recommending
parse_known_args when porting optparse uses.
--
___
Python tracker
<http://bugs.python.
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue14364>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
paul j3 added the comment:
I submitted a patch to http://bugs.python.org/issue9253
The reason why subparser became optional in the latest release is that a old
test for missing positionals was phased out, and new one added. Subparsers
have always had a default 'required=False', b
paul j3 added the comment:
The patch that I recently submitted for http://bugs.python.org/issue13922
appears to solve this issue. It only removes the '--' that marked the end of
options.
With:
parser = argparse.ArgumentParser()
parser.add_argument('-f','--foo&
Paul Price added the comment:
Thanks!
--
___
Python tracker
<http://bugs.python.org/issue17409>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Hoffman added the comment:
Following up on
http://mail.python.org/pipermail/python-ideas/2011-March/009656.html, I would
like to request that struct also handle half-precision floats directly. It's a
short change, and half-precision floats are becoming much more popular in
applica
Paul Melis added the comment:
Here's a patch that removes the
pysqlite_do_all_statements(self, ACTION_RESET, 0);
call.
It also adds the sqlite error code to one of the exceptions raised, as the
error message is misleading in case the ACTION_RESET is left in (I forgot what
sqlite err
Paul Hoffman added the comment:
Whoops, never mind. Thanks for the pointer to 11734.
--
___
Python tracker
<http://bugs.python.org/issue3132>
___
___
Python-bug
Paul Hoffman added the comment:
Just another voice for seeing this put in a deployed version of Python.
Half-precision floats are becoming more common in applications.
Question: does adding this affect math.isnan and math.isinf?
--
nosy: +paulehoffman
paul j3 added the comment:
The attached file has a 'parse_intermixed_args()' that has the same API as
'parse_known_args()'.
It follows the two parse step model
args, remaining_args = optionals.parse_known_args()
args, extras = positionals.parse_known_args(remaining
paul j3 added the comment:
This nargs test using the formater applies only when the container has a help
formatter. That is true for a ArgumentParser, but not for an argument_group.
group = parser.add_argument_group('g')
group.add_argument('bar', nargs='test&#
Paul Hoffman added the comment:
Mark:
>I don't see how math.isnan or math.isinf would be affected: we're not
>proposing to make a float16 Python type, so math.isnan would never encounter a
>float16 value.
I was assuming that this proposal would also make this part of class
Paul Hoffman added the comment:
I *think* what you are saying is that there will be no float16 type, but the
result of struct.unpack('eorwhatever', packed_stuff)[0] will be the same as
struct.unpack('f', packed_stuff)[0], yes? If so, that's what I wanted. I don'
paul j3 added the comment:
Yes, http://bugs.python.org/msg166175 does use 'parse_args' in the second call.
But I think things would be more flexible if we had a second function:
def parse_???(self, args=None, namespace=None):
args, argv = self.parse_intermixed_args(args,
paul j3 added the comment:
This patch adds a value test for nargs during add_argument. The core of the
new test is in ArgumentParser._check_argument.
add_argument() now calls ArgumentParser._check_argument(), which calls
_format_args(). If it gets a TypeError, it raises a metavar ValueError
paul j3 added the comment:
The attached test_nargswarn.py file tests the argparse.py patch. It tries out
various nargs values, both for parsers, groups, and mutually exclusive groups.
I intend to recast these to work in test_argparse.py
--
Added file: http://bugs.python.org
paul j3 added the comment:
This is a revision of yesterday's patch. It includes a couple of test cases
that check that parser, groups, and exclusive groups all produce the error
message.
I also changed the metavar tuple case to return an ArgumentError, and changed
test_argpar
paul j3 added the comment:
http://bugs.python.org/issue9849
also deals with nargs values. However there the focus is on string values like
'1', not whether an integer value can be 0 or <0.
I submitted a patch that moves the nargs testing to a
ArgumentParser._check_argument(
paul j3 added the comment:
An integer nargs value is only used in one of 2 ways,
range(nargs)
'%s'*nargs
In both a negative value acts the same as a 0.
I don't think the original authors though much about 'what if the code user
gives a negative value?', because
paul j3 added the comment:
Correction: The patch I gave in the last message produces:
>>> parser.parse_known_args(['-ku'])
(Namespace(known=False), ['u'])
It doesn't take action on the '-k', and puts 'u&#x
New submission from Paul Moore:
The codecs module allows the user to register additional codecs, but does not
offer a means of getting a list of registered codecs.
This is important, for example, in a tool to re-encode files. It is reasonable
to expect that such a tool would offer a list of
Paul Melis added the comment:
Just a bit more info on the patch. When running stock Python 2.7.4 the attached
test script bug-binding_parameter_0.py returns:
module: 2.6.0
sqlite: 3.7.9
Archives
Archives/2011
Archives/2012
Traceback (most recent call last):
File "bug-binding_parameter
paul j3 added the comment:
Looks like the
text = text.strip()
at the end of the set of regex (in _format_actions_usage) needs to be replaced
with something that removes all excess spaces, e.g.
text = _re.sub( '\s+', ' ', text ).strip()
-
Paul Moore added the comment:
@doerwalter In that case, I'd take the view that such a codec should simply not
return anything. The discovery mechanism can be limited to returning only
statically discoverable codec names (and it can be documented as such).
The original use case was to su
Paul Moore added the comment:
On 2 May 2013 16:35, Dmi Baranov wrote:
> Paul, result as iterable of CodecInfo objects is gives much more
> flexibility than the names of codecs (whats if you will have a few codecs
> with the same name in different SearchObjects?)
Works for me. My us
paul j3 added the comment:
In the test case: class TestMutuallyExclusiveManySuppressed
even with a short 'eggs' argument, there is a difference
Old usage would be:
usage: PROG [-h] [--eggs EGGS]
new
usage: PROG [-h] [--eggs EGGS]
i.e. 2 v 1 space. But extra spaces are not as
paul j3 added the comment:
I see three solutions -
1) gholms' patch which removes '() ' and [] '
2) Yogesh's patch which removes all duplicated spaces.
3) remove the 2 asserts.
The first 2 do the same thing most of the time, but may differ if the user
somehow
New submission from Paul Moore:
The Python launcher for windows should recognise a hashbang line of
#!/usr/bin/env python, and use the python executable found on PATH to run the
script. If no python executable is present on PATH the launcher should fall
back to the current behaviour (using
Paul Moore added the comment:
There is a patch for this (against the standalone pylauncher project) at
https://bitbucket.org/pmoore/pylauncher.
--
keywords: +patch
___
Python tracker
<http://bugs.python.org/issue17
paul j3 added the comment:
This is a revision of the test_intermixed.py that I submitted earlier. Now
`parse_intermixed_args` acts like `parse_args', and calls
`parse_known_intermixed_args`. Again it is form that can exercise the idea
without modifying `argparse.py`.
If the parse
paul j3 added the comment:
This is the formal patch corresponding to the `test_intermixed.py`. It
includes changes to `argparse.rst`, plus tests in `test_argparse.py`. These
tests are near the end, after those for `parse_known_args`. They are roughly
equivalent to the examples in
paul j3 added the comment:
Wouldn't it be simpler to use the re {m,n} notation to grab the appropriate
number of arguments?
In ArgumentParser _get_nargs_pattern we could add:
+# n to m arguments, nargs is re like {n,m}
+elif is_mnrep(nargs):
+nargs_pa
paul j3 added the comment:
I think this patch should build on http://bugs.python.org/issue9849, which
seeks to improve the error checking for nargs. There, add_argument returns an
ArgumentError if the nargs value is not a valid string, interger, or it there
is mismatch between a tuple
paul j3 added the comment:
This patch adds this `nargs='{m,n}'` or `nargs=(m,n)` feature.
It builds on the `better nargs error message` patch in
http://bugs.python.org/msg187754
It includes an argparse.rst paragraph, changes to argparse.py, and additions to
test_argparse.py.
paul j3 added the comment:
'parse_fallback_args()' function is only in the 'test_intermixed.py' file, not
the patch. It should be in the 'if __name__' section of that file, along with
the modified 'exit()' method, since it is part of these
paul j3 added the comment:
I should note one caveat:
As a consequence of setting nargs to 0 for the first 'parse_know_args' step,
all positional entries in the namespace get an empty list value ([]). This is
produced by 'ArgumentParser._get_values'. With the builtin
paul j3 added the comment:
I'm following a dozen argparse issues with patches. I haven't seen much
posting by argparse experts (like bethard, david.murry) since last December.
--
___
Python tracker
<http://bugs.python.o
paul j3 added the comment:
I was wondering about that block of code earlier.
It would be a good idea to look at what func() does, just to make sure there
aren't any side effects - e.g. set maximum line length, required indention, etc.
--
nosy: +pa
New submission from paul j3:
"16.4.3.11. dest
For optional argument actions,... Any internal - characters will be converted
to _ characters to make sure the string is a valid attribute name."
In _get_optional_kwargs(), dest = dest.replace('-', '_'); but
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue14046>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue9338>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
New submission from Paul Jurczak:
This may be too subjective, but here it goes:
PEP 8 discourages vertical alignment: "More than one space around an assignment
(or other) operator to align it with another", but contrary to this rule,
vertical alignment is used many times in the same
Changes by paul j3 :
Removed file: http://bugs.python.org/file29880/mixed.patch
___
Python tracker
<http://bugs.python.org/issue14191>
___
___
Python-bugs-list mailin
Changes by paul j3 :
--
title: argparse does not dest.replace('-', '_') for postionals -> argparse
does not dest.replace('-', '_') for positionals
___
Python
Paul Jurczak added the comment:
Correct, it is in mixed prose and code. However, the underlying principle in
this PEP is: "guidelines provided here are intended to improve the readability
of code". The author used vertical alignment (for mixed prose and code),
because of it
Paul Jurczak added the comment:
I admit, it is somewhat silly, but not entirely silly.
--
___
Python tracker
<http://bugs.python.org/issue17966>
___
___
Python-bug
paul j3 added the comment:
I've played a bit the idea that barthard sketched. I don't have all the
details worked out, but I believe this is what will happen:
With
parser = argparse.ArgumentParser()
parser.add_argument('-w')
parser.add_argument('-x', nargs
paul j3 added the comment:
I need to make one correction to my last post:
'-x 1 2 -w 3 4 5 6', # w:3, x:[1,2], y:4, z:[5,6] +
# w:3, x:[1], y:2, z:[4,5,6] -
The second solution is only possible if 'z' is not consumed when 'y' is
paul j3 added the comment:
This patch implements, I think, the ideas bethard proposed. It is test patch,
not intended for production.
Most of work is in ArgumentParser._get_alt_length() which
- generates a pattern along the lines bethard proposed
- generates a string like arg_strings_pattern
paul j3 added the comment:
This is a test file for the patch I just submitted.
It is not a formal unitttest, but uses print output as much as assert.
Cases include the example bethard used, as well as ones from test_argparse.py
that initially caused problems.
--
Added file: http
Changes by Paul Moore :
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
+1 for Oscar's proposed fix. It sounds like a sensible approach.
--
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
paul j3 added the comment:
Here's another approach to the problem, using an iterative localized search.
For simple cases it produces the same thing, but in complex cases it is more
robust.
It is based on two ideas:
- if the action in consume_optional() is being 'greedy',
Changes by paul j3 :
Removed file: http://bugs.python.org/file30349/argparse_7.py
___
Python tracker
<http://bugs.python.org/issue9338>
___
___
Python-bugs-list mailin
paul j3 added the comment:
Oops, I attached the wrong file. Here's the correct one.
--
Added file: http://bugs.python.org/file30350/issue9338_7.patch
___
Python tracker
<http://bugs.python.org/i
Paul Moore added the comment:
On 23 May 2013 20:11, Roumen Petrov wrote:
> > Is this approach acceptable?
> It is not enough.
>
Support for compilers other than gcc (including cross-compilers) is a
separate issue, and one which is much less likely to
paul j3 added the comment:
In the attached patch I modified 'add_parser' to take a 'parser' keyword
parameter. If given, it is used as the parser, rather than create a new one.
Thus an existing parser, or one created with a custom ArgumentParser class,
could be used a
Paul Moore added the comment:
Not a bad idea. I would want the implementation to remain in the documentation
as well, as code that wants to be portable back to earlier versions of Python
will need it. But for code that targets Python 3.5+ only, having it available
"out of the box"
New submission from Paul Ianas:
The precondition for all the bisect functions is implemented like this:
if lo < 0:
raise ValueError('lo must be non-negative')
if hi is None:
hi = len(a)
Now, of course, if hi is given, and hi >= 2 * len(a), then we get an
Paul Ianas added the comment:
Sure, it is your call. As said, this is rather an enhancement.
Still, if I were to decide, I would chose:
1. not to break the API <=> raise IndexError instead of ValueError in case hi
is invalid.
2. to protect against illegal values: as said, if hi <
paul j3 added the comment:
A possible problem with this patch is that it overrides any Namespace given by
the user. In the test example:
parser.parse_args(['X'], namespace=argparse.Namespace(foo=3))
the result is 'foo=2', the setdefault from the subparser. Previously
paul j3 added the comment:
This issue has already been raise in
http://bugs.python.org/issue9334
argparse does not accept options taking arguments beginning with dash
(regression from optparse)
There I proposed leaving '_negative_number_matcher' unchanged, but only use
paul j3 added the comment:
Patch tests are added to an existing 'Lib/test/test_argparse.py' file. I use
existing test cases as a pattern any new tests.
-
Your test file runs fine with the patch I proposed for Issue 9334.
-
The argparse
Paul Moore added the comment:
This looks reasonable to me.
--
___
Python tracker
<http://bugs.python.org/issue22730>
___
___
Python-bugs-list mailing list
Unsub
Paul Moore added the comment:
Wait, sorry I misread the discussion (long day here). If we can do this in pip
yes that would be better. It looks like we can detect when we're being run via
pythonw by checking if sys.stdout is None.
--
___
P
paul j3 added the comment:
I'm exploring modifying that patch by adding a 'subnamespace' attribute to the
subparsers Action object. This would give the user, or the main parser control
over the namespace that is passed to a subparser.
For example:
subnamespace
paul j3 added the comment:
The patch with a major rewrite of '_format_actions_usage' handles this usage
problem correctly:
usage: try_para_in_meta.py [-h] input_file(s) [input_file(s) ...]
The error is the result of usage group formatter trying to remove excess `()`.
To give
New submission from Paul Moore:
When you install Python 3.4.2 32 bit and 64 bit on the same PC, in that order,
the second one you install shows a red error message on the install screen,
saying "This update will replace your existing Python 3.4 installation", and
proceeds to uninst
paul j3 added the comment:
A notational point - you are adding a subparser, not an argument, to the
subparsers action.
Why would a user want to use `help=argparse.SUPPRESS`, as opposed to simply
omitting the `help` parameter? The effect would be the same as your patch.
Another
paul j3 added the comment:
Related issues are:
http://bugs.python.org/issue13824 - argparse.FileType opens a file and never
closes it
http://bugs.python.org/issue14156 - argparse.FileType for '-' doesn't work for
a mode of 'rb'
As discussed earlier FileType was m
paul j3 added the comment:
This an issue for parse_args as well. parse_args just calls parse_known_args,
and raises an error if extras is not empty.
Early on in parsing, it tries to classify argument strings as either optionals
(--flags) or positionals (arguments). And there's an exp
paul j3 added the comment:
Duplicate of
http://bugs.python.org/issue22433
--
resolution: -> duplicate
___
Python tracker
<http://bugs.python.org/issu
New submission from Paul Hartmann:
HTTPResponse.msg is documented as a http.client.HTTPMessage object containing
the headers of the response [1].
But in fact this is a string containing the status code:
>>> import urllib.request
>>> req=urllib.request.urlopen('http:/
Paul Moore added the comment:
There's a lot of politics around the mingw vs mingw64 situation, but in
practice I believe the various mingw64 builds are fine. So I see no reason not
to supply a correct 64-bit libpythonXY.a.
When the patch was made to include the libpythonXY.a file to th
New submission from Paul Moore:
Patch to make the user scripts directory on Windows
%APPDATA%\Python\PythonXY\Scripts rather than %APPDATA%\Python\Scripts.
See the thread "PEP 370 - per-user scripts directory on Windows" (Feb 10 2015)
on python-dev for discussion, but essentially
Paul Moore added the comment:
Cool, I've just run the tests by manually patching a 3.5a0 install. No extra
failures, so things look fine. (Interestingly, before patching, test_site
"altered the execution environment" but afterwards it didn't - it just
succeeded. I don&
Paul Moore added the comment:
Sorry, yes pip just installs into %APPDATA%\Python\Python35\Scripts with no
issues.
--
___
Python tracker
<http://bugs.python.org/issue23
New submission from Paul Moore:
When building Python (cpython repository, tip revision on the default branch)
using Visual Studio 2015 (version downloaded 12/02/2015) I get a message in the
build:
C:\Work\Projects\cpython\PCbuild\_freeze_importlib.vcxproj(98,5): error :
importlib.h has been
Paul Moore added the comment:
Ah. It's 4K lines of everything changing. Looks like it might be an EOL issue.
The build seems to be changing it from LF line endings to CRLF line endings.
--
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
I'm just about finished for the night but I'll try the eol extension tomorrow.
I don't really use it much, though, my practice is generally to make all my
tools use LF. I certainly didn't do anything that would change that file, so
something
Paul Moore added the comment:
No, enabling the eol extension didn't fix it :-(
--
___
Python tracker
<http://bugs.python.org/issue23461>
___
___
Python-bugs-l
Paul Moore added the comment:
Correction. Looks like if I enable the eol extension, then hg revert
importlib.h, then rebuild, the problem then goes away.
So basically you need the eol extension enabled *before* you update/clone your
checkout
Paul Moore added the comment:
Martin, thanks for the clarification. When I said "I don't use it much" what I
meant was that I've never had it enabled, and for all of the repositories I
use, not doing so has never been a problem (until now). In contrast, git's
a
New submission from Paul Moore:
Implementation of PEP 486 (Make the Python Launcher aware of virtual
environments). Tested manually on my local PC - there aren't currently any
tests for the launcher that I can see (and I'm not entirely sure how I'd write
such a test) so the
Paul Moore added the comment:
Sorry, I should probably have added them to the patch in the first place :-)
--
___
Python tracker
<http://bugs.python.org/issue23
New submission from Paul Moore:
This is the patch for PEP 441 (Zip Application Support).
Steve, could you check the installer changes, please? I haven't managed to get
a setup where I can test the installer, and I'm not aware of any WiX coding
tools, so I just edited the XML fil
Paul Moore added the comment:
Thanks for checking, Steve. I don't get an installer because of the checksum
error quoted, although I did get the component msi files.
As far as content type is concerned, I wasn't sure what effect it had so I just
copied what was there. I guess appli
2301 - 2400 of 3213 matches
Mail list logo
