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:
This is a refinement of the patch with Message188609.
In parse_known_intermixed_args, the temporary capture of formatted usage has
been put in a try/finally structure.
Positionals are now 'deactivated' with
action.nargs = SUPPRESS
action.default
Paul Moore added the comment:
There's also https://pypi.python.org/pypi/sarge
One other thing I *often* want to do when scripting commands is to capture
output, but provide some form of "progress" reporting (something like a dot per
line of output, usually). That's ann
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue9625>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
paul j3 added the comment:
I've added 2 more tests,
one with default='c', which worked before.
one with default=['a','b'], which only works with this change.
http://bugs.python.org/issue16878 is useful reference, since it documents
the differences between
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue16468>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue16418>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
paul j3 added the comment:
chris.jerdonek wrote:
"Also, to answer a previous question, the three places in which the choices
string is used are: in the usage string (separator=','), in the help string
when expanding "%(choices)s" (separator=', '), and in
paul j3 added the comment:
The exit and error methods are mentioned in the 3.4 documentation, but there
are no examples of modifying them.
16.4.5.9. Exiting methods
ArgumentParser.exit(status=0, message=None)
ArgumentParser.error(message)
test_argparse.py has a subclass that
New submission from paul j3:
As discussed in issue 16468, a metavar may be used to provide an alternative
representation of a choices option. However if a metvar like 'range(20)' is
used, usage formatter strips off the '()'.
>>> parser.add_argument('foo&
Changes by paul j3 :
--
components: +Library (Lib)
type: -> behavior
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue18349>
___
___
Py
paul j3 added the comment:
There still is one "choices='XYZ'" example (16.4.5.1. Sub-commands) but the
focus isn't on choices.
--
nosy: +paul.j3
___
Python tracker
<http:
paul j3 added the comment:
test_argparse.py has some "choices='abc'" cases.
In those should "parser.parse_args(['--foo','bc'])" be considered a success or
failure?
The underlying issue here is that while string iteration behaves l
paul j3 added the comment:
Change "choices='abc'" to "choices=['a', 'b', 'c']", as discussed in issue
16977 (use of string choices is a bad example)
--
Added file: http://bugs.python.org/file30762/issue9625_2.patch
_
paul j3 added the comment:
I'd suggest not worrying about the default metavar in the _expand_help()
method. The formatted choice string created in that method is only used if the
help line includes a '%(choices)s' string. The programmer can easily omit that
if he isn&#
paul j3 added the comment:
Changing _check_value from:
def _check_value(self, action, value):
# converted value must be one of the choices (if specified)
if action.choices is not None and value not in action.choices:
...
to
def _check_value(self, action
paul j3 added the comment:
This patch generally deals with the choices option, and specifically the
problems with formatting long lists, or objects that have __contains__
but not __iter__. But it also incorporates issues 9849 (better add_argument
testing) and 9625 (choices with *). It may be
paul j3 added the comment:
I just posted a patch to http://bugs.python.org/issue16468 that deals with this
'bc' in 'abc' issue.
--
___
Python tracker
<http://bug
paul j3 added the comment:
I just posted a patch to http://bugs.python.org/issue16468 that uses (and
tests) this fix.
--
___
Python tracker
<http://bugs.python.org/issue18
paul j3 added the comment:
The patch I just posted to http://bugs.python.org/issue16468 uses this fix.
--
___
Python tracker
<http://bugs.python.org/issue9
paul j3 added the comment:
In the patch I just posted to http://bugs.python.org/issue16468 I address this
long list issue in several ways:
In the Usage line, the metavar gives the user an alternative
In the expanded help line the user can just omit the '%(choices)s'
In _check_
paul j3 added the comment:
I included this patch (with minor changes) in a patch that I just posted to
http://bugs.python.org/issue16468. That issue deals with the argument choices
option, which can be tested along with nargs and metavars
paul j3 added the comment:
This approach of simply adding the existing actions to the group's
_group_actions works fine, at least when it comes catching the error.
It may be difficult to get a useful usage line. In usage, arguments appear in
the order in which they were created, opti
paul j3 added the comment:
One usage option is to make a subclass of HelpFormatter (the accepted way of
customizing a formatter), and write a function that formats each group
independently. For the example case, the resulting format might be:
usage: PROG [-h] [-b] [-a | -c] [-a | -d]
-h
paul j3 added the comment:
While playing with some examples, I found that exclusive group formatting has
another failure case. If the usage line is long enough to wrap, optionals and
positionals are formatted separately, with positionals appearing on a separate
line(s). That means that if a
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue11874>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
paul j3 added the comment:
If the arg_parts are passed through the same cleanup as the 'text' (and empty
strings removed), then
text = ' '.join(arg_parts)
In that case there would be no need to return both (text, arg_parts).
Parenthesis in the metavar could als
paul j3 added the comment:
This patch adds a MultiGroupHelpFormatter that formats groups even if they
share actions or the actions are not in the same order as in the parse._actions
list. It sorts the groups so positional actions, if any appear in the correct
order.
A long test case
paul j3 added the comment:
I just filed a patch with http://bugs.python.org/issue10984 (argparse
add_mutually_exclusive_group should accept existing arguments to register
conflicts) that includes the latest patch from this issue. I tweaked it so
_format_actions_usage only returns arg_parts
paul j3 added the comment:
This issue should also preserve a metavar like: '(one)two', i.e. '(' at the
start.
In http://bugs.python.org/issue10984 these _re replacements are applied to
individual action strings as well as the whole usage line. So if () are to be
re
paul j3 added the comment:
This patch produces the same usage as before, but I have rewritten
_format_actions_usage() for both HelpFormatter and MultiGroupFormater.
The original HelpFormatter._format_actions_usage() formats the actions, splices
in group markings, cleans up the text, if needed
paul j3 added the comment:
Here's a patch that takes a different approach - rewrite
_format_actions_usage() so it formats groups (and unattached actions) directly.
It uses the same logic to determine when to format a group, but then it calls
_format_group_usage() to format the
paul j3 added the comment:
I just submitted at patch to http://bugs.python.org/issue11874 that takes care
of this issue as well.
I rewrote _format_actions_usage() so it formats the parts directly, so there is
no need cleanup or parse the full text string
paul j3 added the comment:
I just submitted a patch to http://bugs.python.org/issue11874 which rewrites
_format_actions_usage(). It now formats the groups and actions directly,
keeping a list of these parts. It no longer has to cleanup or split a usage
line into parts. So it is not
paul j3 added the comment:
I just submitted a patch to http://bugs.python.org/issue11874 that
substantially rewrites _format_actions_usage(). It generates the group and
action parts separately, and does not do the kind of cleanup that produces this
issue
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue18467>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
paul j3 added the comment:
I think this example illustrates your issue:
class FooAction(argparse.Action):
def __call__(self, parser, namespace, values,
option_string = None):
if values=='Q':
setattr(namespace,
New submission from Paul Moore:
Some small improvements to the powershell "Activate" script for venvs:
1. Can be run as a command, rather than needing to be dot sourced. This matches
the behaviour of bat files, and of virtualenv's "activate" script, and avoids a
New submission from Paul Moore:
Adds "exe wrapper" functionality to the Windows launcher. This is a preliminary
patch, for comments - the code is there and works, but I need to add
documentation (and maybe tests - are there any existing tests for the launcher?)
Also to be consider
Changes by Paul Moore :
--
keywords: +patch
Added file: http://bugs.python.org/file30966/launcher_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue18
Changes by Paul Moore :
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue18491>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Correct about .pyw files - I had forgotten those, I will update the patch.
The idea of "support code" was to (somewhat) alleviate Mark's question about
"what is this for", I was wondering if it was worth adding a module to the
stdlib whic
Paul Moore added the comment:
I've no problem with that suggestion. The patch is clean enough that ifdef-ing
it out won't be hard.
Revised patch incoming :-) It's needed for the pyw support in any case.
--
___
Python
paul j3 added the comment:
Since parse_args takes an optional Namespace argument, you can set the its
initial value to almost anything. For example, with the functions defined
previously:
parser = argparse.ArgumentParser()
parser.add_argument('-a','--algorithm&#x
Paul Moore added the comment:
Updated patch, as per discussion.
--
Added file: http://bugs.python.org/file30994/launcher_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue18
Changes by Paul Moore :
Removed file: http://bugs.python.org/file30966/launcher_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue18491>
___
___
Python-bug
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue14074>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
paul j3 added the comment:
My rewrite of _format_actions_usage in http://bugs.python.org/issue11874 should
take care of this issue. It keeps the groups and actions separate until the
final formatting step, bypassing the regular expression parsing.
--
nosy: +paul.j3
paul j3 added the comment:
This patch fixes the problem by joining the metavar terms with '|'. So the
help for the test case (adapted from an existing tuple test) looks like:
usage: PROG [-h] W1 [W2 ...] [X1 [X2 ...]] Y1 Y2 Y3 [Z1]
positional arguments:
W1|W2 w
Paul Winkler <[EMAIL PROTECTED]> added the comment:
Whatever happened with this? I don't see it mentioned in the NEWS file
for the 2.6 line.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Paul Nasrat :
--
nosy: +pnasrat
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Moore :
This patch takes the existing "simplegeneric" decorator, currently an
internal implementation detail of the pkgutil module, and exposes it as
a feature of the functools module.
Documentation and tests have been added, and the pkgutil code has been
upda
Paul Moore added the comment:
Well spotted! I missed that when I checked. I will add tests and
documentation.
I agree that generic is better. I only left it as it was because the
original intent was simply to move the existing code - but that's not a
particularly good reason for keep
Paul Moore added the comment:
Here's an updated patch.
Added file: http://bugs.python.org/file12936/generic.patch
___
Python tracker
<http://bugs.python.org/i
Paul Moore added the comment:
Fair comment. As Ryan said, it's a bit of a bikeshed issue. I prefer
"generic", on the basis that I'd prefer to keep the simple name for the
simple use - something as complex as the RuleDispatch version could use
the name "dispatch"
Paul Moore added the comment:
Agreed about the compatibility. It's there from pkgutil, where to be
honest, it's even less necessary, as simplegeneric was for internal use
only, there. I'm certainly not aware of any backward compatibility
requirements for functools.
Assuming nobo
Paul Melis added the comment:
The "archive" and "subscribe" links for the C++ SIG is incorrect, as the
URL seems to have changed from
http://mail.python.org/pipermail/c++-sig
to
http://mail.python.org/pipermail/cplusplus-sig
---
Paul Moore added the comment:
Agreed (in principle). However, in practice the subtleties of override
order must be documented (and a method of implementation must be
established!!!) Consider:
>>> class A:
... pass
...
>>> class C:
... __metaclass__ = abc.ABCMe
Paul Moore added the comment:
Very good point. Registering for the standard ABCs seems like an
important use case. Unfortunately, it seems to me that ABCs simply don't
provide that capability - is there a way, for a given class, of listing
all the ABCs it's registered under? Even if
Paul Moore added the comment:
Here's an updated patch. I've reverted to the name "simplegeneric" and
documented the limitation around ABCs (I've tried to give an explanation
why it's there, as well as a hint on now to work around the limitation -
let me know if
Paul Moore added the comment:
In principle I don't have a problem with the automatic generation of an
EXE (I assume it generates a shell script with no extension on Unix?)
but it should be done in such a way that the EXE is version-independent.
This is necessary to ensure that pure-p
Paul Boddie added the comment:
The issue of distinguishing between query-originating parameters and
form-originating parameters has been around for a very long time, and
in my own work, especially where the cgi module has been used, I've
been careful to distinguish between the two types a
New submission from Paul Moore :
There is no way to determine the list of classes for which issubclass(C,
x) is true. The MRO of the class is fine for normal inheritance, but for
ABCs it is possible to register classes which don't inherit from the
ABC, so that you have a situation
Paul Moore added the comment:
I raised issue 5405. Armin Roachner commented over there that it's not
even possible in principle to enumerate the ABCs a class implements
because ABCs can do semantic checks (e.g., checking for the existence of
a special method).
So documenting the limitati
Changes by Paul Moore :
___
Python tracker
<http://bugs.python.org/issue5135>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/
Paul Moore added the comment:
I raised issue 5405. Armin Ronacher commented over there that it's not
even possible in principle to enumerate the ABCs a class implements
because ABCs can do semantic checks (e.g., checking for the existence of
a special method).
So documenting the limitati
Paul Moore added the comment:
Good point! So a documentation patch, to the effect that there is no way
of determining which ABCs a given class is an instance of, would be an
appropriate resolution, I guess.
___
Python tracker
<http://bugs.python.
Changes by Paul Moore :
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue2889>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
paul rubin added the comment:
ajaksu2, I don't understand why you want to close this bug if it isn't
fixed. I can accept that it's not the highest priority issue in the
world, but it's something that trips up users from time to time, and it
ix obviously fixable. Closi
paul rubin added the comment:
Daniel, thanks--I didn't mean to jump on you, so I'm sorry if it came
across that way. Maybe I'm a little oversensitized to this issue due to
some unrelated incidents with other programs.
I'll try to write a more detailed reply and maybe incl
Paul Morelle added the comment:
Hello, I can reproduce the bug on a Windows XP Professional, SP 3, with
three versions of Python:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on
win32
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32
401 - 500 of 887 matches
Mail list logo
