paul j3 added the comment:
The test names are:
FAIL: test_failures_many_groups_listargs (__main__.TestFileTypeW)
FAIL: test_failures_many_groups_sysargs (__main__.TestFileTypeW)
FAIL: test_failures_no_groups_listargs (__main__.TestFileTypeW)
FAIL
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue12806>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue13280>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue15428>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
paul j3 added the comment:
It's everything I intend to add. Now I'm just waiting for a committer to act,
either with suggested changes, or a merge. I'm watching more than a dozen
argparse patches.
--
___
Python tracker
<http
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue15112>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
paul j3 added the comment:
Above in
http://bugs.python.org/issue14191#msg187051
I proposed a patch that is quite close to bethard's patch in
http://bugs.python.org/issue15112#msg166173
Both modify the same place, doing the same (pop items off arg_counts). The
logic is a little diff
Changes by paul j3 :
Added file: http://bugs.python.org/file29880/mixed.patch
___
Python tracker
<http://bugs.python.org/issue14191>
___
___
Python-bugs-list mailin
paul j3 added the comment:
I originally posted this on http://bugs.python.org/issue14191, but I think it
belongs here. The patch I proposed is similar to berthard's, popping items off
the end of 'args_counts'. I intend to check whether the logi
Changes by paul j3 :
Removed file: http://bugs.python.org/file29880/mixed.patch
___
Python tracker
<http://bugs.python.org/issue14191>
___
___
Python-bugs-list mailin
paul j3 added the comment:
These three changes end up testing for the same thing. The initial 'if' catches
different test cases. 'subparsers' or 'remainder' might 'confuse' the 'O'
test. The zero-width test ends up weeding out everything but
New submission from Paul Bonser:
lib2to3.pgen2.tokenize:detect_encoding looks for the regex
"coding[:=]\s*([-\w.]+)" in the first two lines of the file without first
checking if they are comment lines.
You can get 2to3 to fail with "SyntaxError: unknown encoding: 0" with
paul j3 added the comment:
A possible further tweak is, in take_action(), test for conflicts before adding
the action to 'seen_non_default_actions'
if argument_values is not action.default:
#seen_non_default_actions.add(action)
for conflict
paul j3 added the comment:
The patch isn't a good unittest case because it produces an Error, not a
Failure. It does, though, raise a valid question about how a
Mutually_exclusive_group tests for the use of its arguments.
As you note, argparse does use the `is` test: `argument_values i
paul j3 added the comment:
A further complication on this. With the arguments I defined in the previous
post
p.parse_args('--foo test --baz 257'.split())
gives the mutually exclusive error message. `sys.argv` does the same.
p.parse_args(['--foo', 'test
paul j3 added the comment:
Changing the test from
if argument_values is not action.default:
to
if argument_values is not action.default and \
(action.default is None or argument_values != action.default):
makes the behavior more consistent. Strings and large ints behave
paul j3 added the comment:
A possibly unintended consequence to this `seen_non_default_actions` testing is
that default values do not qualify as 'present' when testing for a required
mutually exclusive group.
p=argparse.ArgumentParser()
g=p.add_mutually_exclusive_group(req
paul j3 added the comment:
I should add that defaults with required arguments (or groups?) doesn't make
much sense. Still there's nothing in the code that prevents it.
--
___
Python tracker
<http://bugs.python.o
paul j3 added the comment:
This `argument_values` comes from `_get_values()`. Most of the time is derived
from the `argument_strings`. But in a few cases it is set to `action.default`,
specifically when the action is an optional postional with an empty
`argument_strings
paul j3 added the comment:
At the very least the `is not action.default` needs to be changed. Else where
in argparse `is` is only used with `None` or constant like `SUPPRESS`. So
using it with a user defined parameter is definitely not a good idea.
Possible variations on how `is` behaves
paul j3 added the comment:
This patch uses a narrow criteria - if `_get_values()` sets the value to
`action.default`, then argument counts as 'not present'. I am setting a
`using_default` flag in `_get_values`, and return it for use by `take_action`.
In effect, the only change fro
New submission from Paul Colomiets :
Attached patch is a partial implementation of PEP 419, it lacks inspect module
functions and requires more unit tests.
--
components: Interpreter Core
files: cleanuphook.patch
keywords: patch
messages: 159994
nosy: tailhook
priority: normal
severity
New submission from Paul Upchurch :
To reproduce the error:
Python 3.2.2 (default, Sep 5 2011, 22:09:30)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> slice(0,9,None).indices(126)
T
Paul Upchurch added the comment:
Sorry. I didn't realize there was a 3.2.3 out. I'll close it as fixed.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.py
Paul Upchurch added the comment:
That's true; it doesn't work with today's downloads from python.org. The
version I tested was win32 but I don't think that should matter. Python has
always supported large numbers on 32-bit OSs.
My observations:
[1] Debian Wheezy, py
Paul Upchurch added the comment:
The pre-built 64-bit Windows binaries from python.org works.
Python 3.3.0a3 (default, May 1 2012, 16:46:00) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>
Changes by Paul Cauchon :
--
nosy: +Paul.Cauchon
___
Python tracker
<http://bugs.python.org/issue13952>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Nasrat added the comment:
I stepped through in pdb
(Pdb) p i
<_frozen_importlib.FileFinder object at 0x101066090>
(Pdb) iter_importer_modules(i, prefix)
[]
(Pdb) p hasattr(importer, 'iter_modules')
False
2.7 uses
[]
(Pdb) pp dir(myimp)
['__doc__', '__init
Paul Nasrat added the comment:
I was pretty tired when debugging last night and just quickly looked at hg
logs, so that may be misattributed.
I'll try come up with a clearer reproducer.
--
___
Python tracker
<http://bugs.python.org/is
Paul Nasrat added the comment:
Ok so it seems I can't just use sys.meta_path in pip to work with ImpImporter
due to according to the pydoc:
Note that ImpImporter does not currently support being used by placement on
sys.meta_path.
I guess I can write a custom importer in pip for han
New submission from Paul Nasrat :
Whilst looking for workarounds to http://bugs.python.org/issue14982 I came
across this, which is due to inspect using warnings without having importing it.
Fix is trivial but can upload a patch
Traceback (most recent call last):
File "t.py",
Paul Nasrat added the comment:
We've taken a simpler approach avoiding walk_packages in pip which we'll
release for 3.3. I'd say if pkgutil doesn't work correctly with importers &
loaders outside of it we probably should make that very explicit in the docs,
Paul Moore added the comment:
Applies and builds cleanly on Win7 32-bit. The speed difference is visible here
too:
PS D:\Data\cpython\PCbuild> .\python.exe -m timeit -s "from _thread import
allocate_lock; l=allocate_lock()" "l.acquire();l.release()"
100 loops, be
Paul Boddie added the comment:
On Wednesday 13 June 2012 23:51:25 Alexander Belopolsky wrote:
> Alexander Belopolsky added the comment:
>
> I've simplified Paul's patch by removing timegm and mktimetz functions.
> Also, platforms that don't support tm_zone are u
Paul Moore added the comment:
The applied fix appears to have a regression - the file argument is not allowed
to be None. The pywin32 post-install script calls imp.load_module for a C
extension with file=None, so presumably this worked in earlier versions.
The regression breaks the
Paul Moore added the comment:
On 10 September 2012 11:47, Tim Golden wrote:
>
> Tim Golden added the comment:
>
> Paul, are you using the hg tip of pywin32? pywin32_postintall.py was
> patched a couple of months ago to use imp.load_dynamic (essentially to
> work around this is
New submission from Paul Moore:
imp.load_module appears to have a regression - the file argument is not allowed
to be None when loading a C_EXTENSION. The pywin32 post-install script for
version 217 calls imp.load_module for a C extension with file=None, so
presumably this worked in earlier
Paul Moore added the comment:
Logged as #15902.
--
___
Python tracker
<http://bugs.python.org/issue15828>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
It's the open file object argument, not the path. I assume that if you
supplied None, the code opened the file for you.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org
New submission from Paul Wiseman:
I found this behaviour today and thought it was weird so asked the question on
SO here
http://stackoverflow.com/questions/12632894/why-doesnt-getattr-work-with-exit/12632972#12632972
basically if I attributes are returned dynamically, they seem to get
Paul Wiseman added the comment:
I got pointed to an explanation in the docs!
http://docs.python.org/reference/datamodel.html#special-method-lookup-for-new-style-classes
It was confusing, though :)
--
resolution: -> invalid
status: open ->
Changes by Paul Moore :
--
nosy: -pmoore
___
Python tracker
<http://bugs.python.org/issue13198>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
I've been around here for a while, but yeah, I'll keep an eye out for pip stuff
now, too. Good thought.
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.o
paul j3 added the comment:
Yes, the documentation is accurate but a bit vague. It doesn't say how 'it
uses sys.arg[0]'. The example implies it uses 'basename'. So the question is,
whether that implementation detail should be more explicit?
paul j3 added the comment:
The relevant code is:
prog = _os.path.basename(_sys.argv[0])
--
___
Python tracker
<http://bugs.python.org/issue20970>
___
___
paul j3 added the comment:
Cross reference for sys.argv[0] is
http://docs.python.org/3.4/library/sys.html
> ___
>
--
___
Python tracker
<http://bugs.python.org/i
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue14156>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
>From http://bugs.python.org/issue14156
"argparse.FileType for '-' doesn't work for a mode of 'rb'"
I learned that 'stdin/out' can be embedded in an 'open' by using the 'fileno()'
and 'clos
paul j3 added the comment:
A related issue http://bugs.python.org/issue13824
"argparse.FileType opens a file and never closes it"
I proposed a FileContext class that returns a `partial(open, filename,...)'
context object. The issues of how to deal with stdin/
paul j3 added the comment:
There are a couple of complications to using 'fileno'.
We probably don't want to close 'sys.stdin' or 'sys.stdout' (not even if they
are redirected to other files?). That means using:
open(sys.stdin.fileno(), ..., closefd=F
Changes by Paul Sokolovsky :
--
nosy: +pfalcon
___
Python tracker
<http://bugs.python.org/issue17145>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Sokolovsky:
With bytearray, you can do:
>>> bytearray(3)
bytearray(b'\x00\x00\x00')
However, with arrays:
>>> array.array('i', 3)
Traceback (most recent call last):
File "", line 1, in
TypeError: 'int
Paul Sokolovsky added the comment:
> It's not clear to me that importing specifier prefixes from the struct module
> is the best way to go about this, though.
What are other alternatives then? Using struct's syntax has obvious benefit of
being consistent and not confusing pe
Paul Sokolovsky added the comment:
See also http://bugs.python.org/issue17345
--
___
Python tracker
<http://bugs.python.org/issue9066>
___
___
Python-bugs-list m
Paul Sokolovsky added the comment:
See also http://bugs.python.org/issue9066
--
nosy: +pfalcon
___
Python tracker
<http://bugs.python.org/issue17345>
___
___
Pytho
paul j3 added the comment:
http://stackoverflow.com/questions/22929087
A question that could be addressed with this patch(es)
In a subparser:
I have 4 arguments: -g, -wid, -w1, and -w2.
-w1 and -w2 always appear together
-wid and (-w1 -w2) are mutually exclusive, but one or the
paul j3 added the comment:
While 'argparse' is complex, its organization is quite different from
'itertools'. For most purposes there is one starting point:
parser = argparse.ArgumentParser(...)
Nearly everything else invokes a 'parser' method. Most comple
paul j3 added the comment:
http://stackoverflow.com/questions/22990977/why-does-this-argparse-code-behave-differently-between-python-2-and-3
is answered by this change in how `required` arguments are tested, and how
subparsers fell through the cracks
Paul Sokolovsky added the comment:
> >>> array.array('i', [0]) * 3
@Serhiy Storchaka:
The keyword is "efficiently". Let's analyze: this creates useless
array.array('i', [0]) object destined only for garbage collection. Then, it
forces using
Paul Sokolovsky added the comment:
@Terry J. Reedy:
Thanks for the pointer. My inital response is , another bloating of
namespace. But I'm adjusting.
But that PEP shows the issue with all that activity: CPython stdlib got so big
and bloated, that it lives its own life and people consid
Paul Sokolovsky added the comment:
Martin:
> People might expect that array.array('i', 3) creates an array with the single
> value 3.
I don't know which people would expect that. Personally I recognize the need to
create an empty array of of given size, and have read
paul j3 added the comment:
While mutually exclusive groups are a subclass of argument groups, they have
very different uses.
Argument groups are used solely to organize the help section. Groups are not
used at all during parsing. 'parse_args' doesn't even pay attention to t
paul j3 added the comment:
Using a mutually_exclusive_group is a little more complicated than I implied in
the previous post.
p=argparse.ArgumentParser()
g=p.add_mutually_exclusive_group()
# currently the code objects to 'title' and 'description' keywords
g
paul j3 added the comment:
The attached file implements a solution using a subclassed ArgumentParser and a
.add_titled_mutually_exclusive_group method (two versions).
I changed the test conditions a bit, removing a blank line, and making the
usage 'exclusive'.
--
Added
paul j3 added the comment:
The idea of nesting a mutually_exclusive_group in a titled argument_group is
already present in `test_argparse.py`.
class TestMutuallyExclusiveInGroup(MEMixin, TestCase):
def get_parser(self, required=None):
parser = ErrorRaisingArgumentParser(prog
paul j3 added the comment:
oops - one more glitch (revealed by TestMutuallyExclusiveInGroup):
'add_mutually_exclusive_group' accepts a 'required' argument, but
'add_argument_group' does not. So 'add_titled_mutually_exclusive_group' needs
to be changed
paul j3 added the comment:
Another example of code hitting this AssertionError. Here the problem was a
space in the option argument, '--out '.
http://stackoverflow.com/questions/23159845/python-argparse-assertionerror
'parser.add_argument('-o', '--out '
paul j3 added the comment:
http://bugs.python.org/issue14191
implements the other side of optparse behavior - allowing a complete
intermixing of optionals and positionals.
It does that with a new 'ArgumentParser.parse_intermixed_args()
paul j3 added the comment:
http://bugs.python.org/issue15112
breaks one test that I added to issue
+class TestPositionalsAfterOptionalsPlus(ParserTestCase):
+"""Tests specifying a positional that follows an arg with nargs=+
+http://bugs.python.org/issu
Changes by paul j3 :
Added file: http://bugs.python.org/file35028/format_usage.patch
___
Python tracker
<http://bugs.python.org/issue11874>
___
___
Python-bugs-list mailin
Changes by paul j3 :
Removed file: http://bugs.python.org/file30941/format_usage.patch
___
Python tracker
<http://bugs.python.org/issue11874>
___
___
Python-bugs-list m
paul j3 added the comment:
This patch adds a ReGroupHelpFormatter class, which regroups positional
arguments in the usage line as discussed before. It builds on the reworked
usage formatter in bugs/python.org/issue11874 (which keeps usage as a list
longer).
For a complicate parser, usage
paul j3 added the comment:
This is a testing script for this patch. It is not a unit test.
Example:
p = argparse.ArgumentParser()
p.formatter_class = argparse.ReGroupHelpFormatter
p.add_argument('foo')
p.add_argument('arg1',nargs='?')
p.add_ar
paul j3 added the comment:
oops - to fix the error message that OP complained about, I need to patch
'_get_action_name' as well:
def _get_action_name(argument):
...
elif argument.metavar not in (None, SUPPRESS):
metavar = argument.metavar
if
paul j3 added the comment:
This patch fixes both help and error formatting.
A module level '_format_metavars' does the formatting for both.
I have tried several alternatives, including using the 'usage' style.
There is similarity between this fix and that for issue 1
New submission from Paul Sokolovsky:
It caused me a big surprise that asyncio.Task object automatically schedules
itself in the main loop for execution upon creation (i.e. in constructor).
Nowhere in the main reference part of section "18.5.2.4. Task"
(https://docs.python.org/3
Paul Sokolovsky added the comment:
Based on discussion
https://groups.google.com/forum/#!topic/python-tulip/zfMQIUcIR-0 . That
discussion actually questions the grounds of such Task behavior, and points it
as a violation of "Explicit is better than implicit" principle, and as
in
paul j3 added the comment:
Another Stackoverflow question triggered by this issue
http://stackoverflow.com/questions/23349349/argparse-with-required-subparser
--
___
Python tracker
<http://bugs.python.org/issue9
paul j3 added the comment:
There's a complicating issue - should these default values be passed through
the type function?
In most cases in `_get_values`, the string first goes through `_get_value`, and
then to `_check_value`.
For example the 'else:' case:
Changes by paul j3 :
Added file: http://bugs.python.org/file35128/notes.txt
___
Python tracker
<http://bugs.python.org/issue9625>
___
___
Python-bugs-list mailin
paul j3 added the comment:
I encountered a conflict when merging this patch with
http://bugs.python.org/issue15112. In my first testcase, 'cmd' and 'rest'
failed the 'required' test in phase one of 'intermixed'. That's because 15112
postponed par
Paul Moore added the comment:
Checking the exact error could be a bit fragile. I have a feeling I recently
saw an issue somewhere with code that stopped working on Python 3.4 because the
precise error raised for a read-only file changed. I don't recall where the
issue was, unfortun
paul j3 added the comment:
Update the patch -
test_argparse.py - cleanup spaces
argparse.rst - merging conflicts
--
Added file: http://bugs.python.org/file35190/issue14910_2.patch
___
Python tracker
<http://bugs.python.org/issue14
Changes by paul j3 :
Removed file: http://bugs.python.org/file35190/issue14910_2.patch
___
Python tracker
<http://bugs.python.org/issue14910>
___
___
Python-bugs-list m
Changes by paul j3 :
Added file: http://bugs.python.org/file35191/issue14910_2.patch
___
Python tracker
<http://bugs.python.org/issue14910>
___
___
Python-bugs-list mailin
New submission from Paul Sokolovsky:
fnmatch.translate() ends with:
return res + '\Z(?ms)'
However, https://docs.python.org/3.4/library/re.html#regular-expression-syntax
states:
Note that the (?x) flag changes how the expression is parsed. It should be used
first in the express
Changes by Paul Sokolovsky :
--
title: fnmatch module uses undefined regular expression to perform matching ->
fnmatch module uses regular expression with undefined result to perform matching
___
Python tracker
<http://bugs.python.org/issu
paul j3 added the comment:
When `add_subparsers` creates the `_prog_prefix` it uses a list of positionals.
That makes sense, since a subparser argument is positional, so the user needs
to know where it fits in the broader scope of positionals.
But it intentionally skips the 'optionals&#
Changes by paul j3 :
Added file: http://bugs.python.org/file35204/sample.py
___
Python tracker
<http://bugs.python.org/issue20333>
___
___
Python-bugs-list mailin
Paul Sokolovsky added the comment:
I see, so it's my misreading of the "re" module docs. I kinda thought that "x"
in "(?x)" means "any single-character flag of set (?aiLmsux)". I was wrong, it
is the specific literal flag.
Also, rereadin
paul j3 added the comment:
An alternative to passing a Formatter instance to the parser is to use a
wrapper function. `HelpFormatter.__init__` takes several keyword args.
'_get_formatter' does not use those. However we could define:
def format_wrapper(**kwargs):
# clas
paul j3 added the comment:
An alternative to adding a 'ParagraphFormatter' class to 'argparse', is to
format the individual text blocks PRIOR to passing them to the 'parser', and
use the 'RawTextHelpFormatter'.
In the attached script I use a simple
New submission from Paul Sokolovsky:
Lib/quopri.py for version 3.3..3.5-tip contains following code:
ESCAPE = b'='
...
line = input.readline()
if not line: break
i, n = 0, len(line)
if n > 0 and line[n-1:n] == b'\n':
...
el
Paul Sokolovsky added the comment:
This is minor issue indeed, uncovered when trying to run quopri.py with
MicroPython http://micropython.org . I now worked around this on MicroPython
side, but otherwise I set to report any issues I've seen with MicroPython
porting, in the hope
Changes by paul j3 :
Added file: http://bugs.python.org/file35306/wrap_sample.py
___
Python tracker
<http://bugs.python.org/issue12806>
___
___
Python-bugs-list mailin
Changes by paul j3 :
Removed file: http://bugs.python.org/file35236/wrap_sample.py
___
Python tracker
<http://bugs.python.org/issue12806>
___
___
Python-bugs-list mailin
paul j3 added the comment:
Last year someone asked on Stackoverflow about using 'type=bool'. My answer is
at:
http://stackoverflow.com/questions/15008758/parsing-boolean-values-with-argparse/19233287#19233287
'type' is supposed to be a function that takes a string, and co
paul j3 added the comment:
Two points to keep in mind:
'argparse' works with 'sys.argv[1:]'. If that does not contain what you want,
then you can pass your own 'argv' to 'parse_args'.
'type=bytes' means, call the builtin 'bytes'
paul j3 added the comment:
'invalid bytes value' is the error message generated by 'argparse'. The
underlying error (for a string like 'xxx') is:
print(bytes(sys.argv[1]))
TypeError: string argument without an encoding
You could use 'bytes' i
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue10523>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
1801 - 1900 of 3045 matches
Mail list logo
