New submission from Devin Jeanpierre jeanpierr...@gmail.com:
In trunk/Doc/reference/datamodel.rst , under _Implementing Descriptors_, the
documentation states:
`The following methods only apply when an instance of the class containing the
method (a so-called *descriptor* class) appears
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
PyObject_RichCoareBool is, according to the documentation in trunk
(Doc\c-api\object.rst), exactly the same as PyObject_RichCompare, except it 1,
0, or -1 for error, false, and true respectively. However, it differs in
behavior
New submission from Devin Jeanpierre:
I was slightly misled by the wording of part of the docs
(http://docs.python.org/lib/bltin-file-objects.html):
file() is new in Python 2.2. The older built-in open() is an alias
for file().
I actually thought it meant that open was an alias of file, so
New submission from Devin Jeanpierre [EMAIL PROTECTED]:
In the curses module documentation http://docs.python.org/lib/module-
curses.html , there is a link to a curses-howto, at
http://www.python.org/doc/howto/curses/curses.html . That page doesn't
exist: it gives an HTTP 404.
I am aware
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
I can confirm this behavior on 2.7. On 3.2 for me it prints done., but not
Interrupted!
--
nosy: +Devin Jeanpierre
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10837
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
Sorry, forgot to mention my system. 64-bit Windows 7.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10837
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
Windows 7 64-bit (on the metal, not in a VM), can confirm. Holding down Ctrl+C
will (eventually) halt Python on all the versions I have installed: 2.3, 2.7,
3.0, 3.1, 3.2. (All of these are 32-bit Pythons). Haven't done anything silly
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
The usage string details a -v option, but python -m doctest doesn't use a -v
option.
The attached patch adds that.
--
files: doctest_verbosity.diff
keywords: patch
messages: 133195
nosy: Devin Jeanpierre
priority: normal
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
*Sigh*, I'm just confused. Sorry, must have screwed up what I passed as verbose
somewhere, so that it didn't check sys.argv.
--
resolution: - invalid
status: open - closed
versions: +Python 3.3 -Python 3.2
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
From the doctest source:
'Option directives are comments starting with doctest:. Warning: this may
give false positives for string-literals that contain the string #doctest:.
Eliminating these false positives would require
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
Tokenizing `' 1 2 3` versus `''' 1 2 3` yields different results.
Tokenizing `' 1 2 3` gives:
1,0-1,1:ERRORTOKEN '
1,2-1,3:NUMBER '1'
1,4-1,5:NUMBER '2'
1,6-1,7:NUMBER '3'
2,0-2,0
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
C11 uses 'x' for this, for what it's worth.
This is not a duplicate issue. The openat solution is no easier than the
os.open solution.
--
nosy: +Devin Jeanpierre
___
Python tracker rep
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
Amaury did not suggest to use openat, but the new opener argument to open,
which was especially added for use cases such as the one discussed here:
Sorry, yes. Wrong words, same thought. We can implement this using opener, but
we
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
What follows is a copy-paste of a shell session. Notice that at the end, rather
than being inside the online help utility, I'm still in the interactive
interpreter. I was able to duplicate this on python3.2, python2.7, and
python2.6
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
IMO, help('help') should document the help function, not start an interactive
help session (that’d be help()).
Ahhh, that explains it. help('help') isn't ever meant to be called; it's
supposed to be:
help()
...
help help
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
In practice, I expect that a pure Python implementation of a regular
expression engine would only be fast enough to be usable on PyPy.
Not sure why this is necessarily true. I'd expect a pure-Python implementation
to be maybe 200
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
It'd be nice if we had some sort of representative benchmark for real-world
uses of Python regexps. The JS guys have all pitched in to create such a thing
for uses of regexps on thew web. I don't know of any such thing for Python.
I
New submission from Devin Jeanpierre:
Many executables in python are meant to be run on python scripts, but can't run
python scripts that are part of a package. For example, one can do `python -m
pdb foo.py`, but not `python -m pdb package.foo`. This makes it more difficult
to interact
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
You're right, and good catch. If a doctest starts with a #coding:XXX line,
this should break.
One option is to replace the call to tokenize.tokenize with a call to
tokenize._tokenize and pass 'utf-8' as a parameter. Downside: that's
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
It's probably best shown by example:
http://ideone.com/4YkqV
Have fun! This one looks hard.
Some notes: Exchanging g2() for iter([1]) makes this go away. Wrapping g2
inside a non-generator iterator does not make this go away
Changes by Devin Jeanpierre jeanpierr...@gmail.com:
Removed file: http://bugs.python.org/file22550/exception_chaining.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12475
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
Updated patch to newest revision, and to use _tokenize function and includes a
test case to verify that it ignores the encoding directive during the
tokenization (and every other) step.
I'll file a tokenize bug separately
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
Erp I forgot to run this against the rest of the tests. Disregard, I'll fix it
up a bit later.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11909
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
Updated.
--
Added file: http://bugs.python.org/file22562/comments3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11909
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
tokenize only deals with bytes. Users might want to deal with unicode source
(for example, if python source is embedded into a document with an
already-known encoding).
The naive approach might be something like:
def my_readline
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
(this is copy-pasted from
http://mail.python.org/pipermail/python-ideas/2011-July/010787.html )
compile('1\n2\n', '','single') == compile('1\n', '','single').
That is, it ignores the second statement ('2\n'),
without offering a way
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
This is a duplicate of http://bugs.python.org/issue12947
--
nosy: +Devin Jeanpierre
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14865
Changes by Devin Jeanpierre jeanpierr...@gmail.com:
--
title: Examples in library/doctest.html lack the flags - doctest directive
examples in library/doctest.html lack the flags
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
For extra clarification, this issue can crop up with even a single press of
ctrl-c. It's not really related to multiple presses, except that pressing it
more increases the odds of it happening.
--
nosy: +Devin Jeanpierre
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
compiled regex objects' match method offers an optional pos parameter
described to be roughly equivalent to slicing except for how it treats the ^
operation. See http://docs.python.org/library/re.html#re.RegexObject.search
However
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
If it's intended behaviour, then I'd request that the documentation
specifically mention lookbehind assertions the way it does with ^.
Saying it's slightly different doesn't make clear the ways in which it is
different, and that's
New submission from Devin Jeanpierre:
http://docs.python.org/3.4/library/binascii.html#binascii.hexlify
--
assignee: docs@python
components: Documentation
messages: 201376
nosy: Devin Jeanpierre, docs@python
priority: normal
severity: normal
status: open
title: binascii.hexlify docs say
New submission from Devin Jeanpierre:
As far as I can tell, the only safe and correct way to convert a (for example)
intptr_t to a python long is something akin to the following:
size_t repsize = sizeof(intmax_t)*8 + 2;
char i_buf[repsize]; // enough to fit base 2 with sign, let alone
Devin Jeanpierre added the comment:
PyLong_FromVoidPtr works for uintptr_t, but not intptr_t.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17870
Devin Jeanpierre added the comment:
With regards to the title change, I would prefer a FromIntMax_t (and
FromUintMax_t) to a FromIntPtr_t. The former covers every use case of the
latter, and more.
--
___
Python tracker rep...@bugs.python.org
http
Devin Jeanpierre added the comment:
Isn't it possible for a 64-bit architecture to have intptr_t be wider than
long long?
As for my use-case, I am wrapping the C-API for Rust. Rust can call and be
called by C (and therefore Python), but a Rust int is a C intptr_t, and a
Rust uint is a C
Devin Jeanpierre added the comment:
I don't know what context these types are being used in, but would
int_least64_t suffice? C99 does require the existence of the [u]int_leastN_t
types (for N in {8,16,32,64}), unlike [u]intN_t.
--
___
Python
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
The documentation uses the function signature
`abc.abstractproperty(fget[, fset[, fdel[, doc]]])`, implying that
fget is mandatory, and all other arguments are optional. The correct
version would be `abc.abstractproperty([fget
New submission from Devin Jeanpierre:
http://docs.python.org/3.4/library/functions.html#open says newline controls
how universal newlines mode works (it only applies to text mode).
My reading of this when I saw it was that newline= doesn't do anything unless
universal newlines mode is enabled
New submission from Devin Jeanpierre:
If another thread is active during interpreter shutdown, it can hold the last
reference to a handler; when it drops that reference, the weakref callback --
_removeHandlerRef -- will be executed in this other thread. So while this
callback is running
Devin Jeanpierre added the comment:
Are you sure? There should have been many previous contributions by Google, so
the relevant copyright agreements _should_ have already been signed.
I asked internally and was told that a corporate version of this agreement had
been signed a long time ago
Devin Jeanpierre added the comment:
Please don't take my word for it, but my understanding is that this issue
doesn't apply to 3.4+ since module globals are no longer set to None during
interpreter shutdown. (So all the checks against None could even be deleted
Changes by Devin Jeanpierre jeanpierr...@gmail.com:
--
nosy: +Devin Jeanpierre
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22785
___
___
Python
New submission from Devin Jeanpierre:
[] = ()
() = []
File stdin, line 1
SyntaxError: can't assign to ()
This contradicts the assignment grammar, which would make both illegal:
https://docs.python.org/3/reference/simple_stmts.html#assignment-statements
--
components: Interpreter
New submission from Devin Jeanpierre:
The port to reST missed the second example:
https://docs.python.org/release/2.5/lib/node867.html
This is still referred to in the docs, so it is not deliberate. For example,
the token module docs say The second example for the parser module shows how
Devin Jeanpierre added the comment:
A wild patch appears!
Test is included, I'm unhappy with it, because it uses one test method to test
all of Sequence, but that's what the test suite does for MutableSequence.
--
keywords: +patch
nosy: +Devin Jeanpierre
Added file: http
Devin Jeanpierre added the comment:
I inferred from Serhiy's comment that if you override __iter__ to be efficient
and not use __getitem__, this overridden behavior used to pass on to index(),
but wouldn't after this patch.
--
___
Python tracker
Devin Jeanpierre added the comment:
Yes, also, it is documented:
https://docs.python.org/3/library/decimal.html#decimal.InvalidOperation
Still, the status quo is bad. At the very least there should be clear
documentation on how Decimal differs in behavior from floats and ints. (Other
than
Devin Jeanpierre added the comment:
I'm going to add a test case that changes the sequence length during .index(),
and just do whatever list does in that case.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23086
New submission from Devin Jeanpierre:
import decimal
x = 0
y = float(x)
z = decimal.Decimal(x)
x == y == z == x
True
x ** x
1
y**y
1.0
z**z
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/decimal.py, line 2216, in __pow__
return context
Changes by Devin Jeanpierre jeanpierr...@gmail.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23201
___
___
Python-bugs
Devin Jeanpierre added the comment:
I take it back, I don't want to copy what the list type does, because it's
wrong: http://bugs.python.org/issue23204
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23086
New submission from Devin Jeanpierre:
class AppendOnUnequal(object):
... def __init__(self, append_to):
... self.append_to = append_to
... def __eq__(self, other):
... if self is other:
... return True
... self.append_to.append(self
Devin Jeanpierre added the comment:
Does the spec have a handy list of differences to floats anywhere, or do you
have to internalize the whole thing?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23201
Devin Jeanpierre added the comment:
copy() should not be implemented magically, no.
I understand the argument in favor of not implementing redundant methods, but
if the redundancy was this big a concern, they should not have been added to
sets in the first place. The current ABCs
Devin Jeanpierre added the comment:
Thanks for the patch! I was secretly hoping to write it though. :P
Not sure how the code review tool works. The patch looks good to me, except it
needs tests IMO. I can write them if you think this is not worth the effort
New submission from Devin Jeanpierre:
set(dir(set)) - set(dir(collections.abc.MutableSet))
{'copy', 'update', '__rsub__', 'union', 'issubset', 'intersection',
'issuperset', '__rxor__', 'difference', 'symmetric_difference',
'difference_update', '__rand__', 'intersection_update
Changes by Devin Jeanpierre jeanpierr...@gmail.com:
--
components: +Library (Lib)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23161
New submission from Devin Jeanpierre:
For sequence __contains__ and other scenarios, identity is checked before
equality, which I've heard is so that for x in y: assert x in y doesn't ever
fail with an AssertionError (even with NaN and so on). This is not the case for
collections.abc-based
Devin Jeanpierre added the comment:
See Raymond Hettinger's comments in http://bugs.python.org/issue4296 for
details on why the usual sequence behavior is deliberate.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23162
Devin Jeanpierre added the comment:
I think that such a thing is meaningless, as I don't own copyright to the
patches, my employer (Google) does. But, it can't hurt, so, done.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Devin Jeanpierre added the comment:
Since both patches will clobber each other (same test method), complicating the
review process, I've written the patch for issue23086 first. It's currently
waiting on committee review from my employer. Will upload to other issue, and
once it's submitted
Devin Jeanpierre added the comment:
I modified your test case somewhat. Also, your tests uncovered an issue with
negative indexes -- oops, hadn't thought of those. Fixed. Let me know what you
think.
--
Added file: http://bugs.python.org/file37631/issue23086.2.patch
Devin Jeanpierre added the comment:
Why is there no review link next to my second patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23086
Devin Jeanpierre added the comment:
Are you sure? I noticed that __iter__ went out of its way to avoid calling
len().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23086
New submission from Devin Jeanpierre:
Maybe the functions should be split up into those you shouldn't need to call
directly, and those you should? I find it unlikely that you're supposed to use
codecs.encode(..., 'hex') and codecs.decode(..., 'hex') instead of binascii
(the only other thing
New submission from Devin Jeanpierre:
If a subclass has abstract methods, it fails to instantiate... unless it's a
metaclass, and then it succeeds.
import abc
class A(metaclass=abc.ABCMeta):
... @abc.abstractmethod
... def foo(self): pass
...
class B(A): pass
...
B()
Traceback
Devin Jeanpierre added the comment:
This bug also affects 2.7. The main problem I'm dealing with is
sys._current_frames will then return wrong stack frames for existing threads.
One fix to just this would be to change how the dict is created, to keep newer
threads rather than tossing them
Devin Jeanpierre added the comment:
[a, b] = (1, 2) is also fine.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23275
___
___
Python-bugs-list
Devin Jeanpierre added the comment:
Here's a backport of the patch to 2.7. It's pretty rad, and basically identical
to how YouTube monkeypatches base64.
Not sure what will happen to this patch. According to recent discussion on the
list (e.g. https://mail.python.org/pipermail/python-dev/2015
Devin Jeanpierre added the comment:
The patch I'm providing with this comment has a ... really hokey test case, and
a two line + whitespace diff for pystate.c . The objective of the patch is only
to have _current_frames report the correct frame for any live thread. It
continues to report dead
Devin Jeanpierre added the comment:
Agree with Charles-François's second explanation. This makes it very hard to
reliably handle signals -- basically everyone has to remember to use
set_wakeup_fd, and most people don't. For example, gunicorn is likely
vulnerable to this because it doesn't use
Devin Jeanpierre added the comment:
Adding haypo since apparently he's been touching signals stuff a lot lately,
maybe has some useful thoughts / review? :)
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5315
New submission from Devin Jeanpierre:
The code attached runs a while loop that prints, and has a signal handler that
also prints. There is a thread that constantly fires off signals, but this is
just to ensure the condition for the bug happens -- this is a bug with signal
handling
Devin Jeanpierre added the comment:
It doesn't do any of those things in Python 2, to my knowledge. Why aren't we
willing to make this work?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24283
Devin Jeanpierre added the comment:
Sorry, forgot to link to docs because I was copy-pasting from the PR:
https://docs.python.org/2/c-api/typeobj.html#c.PyTypeObject.tp_richcompare
https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_richcompare
> Note: If you want to implem
New submission from Devin Jeanpierre:
am not sure when TypeError is the right choice. Definitely, most of the time
I've seen it done, it causes trouble, and NotImplemented usually does something
better.
For example, see the work in https://bugs.python.org/issue8743 to get set to
interoperate
Devin Jeanpierre added the comment:
Yeah, I agree there might be a use-case (can't find one offhand, but in
principle), but I think it's rare enough that you're more likely to be led
astray from reading this note -- almost always, NotImplemented does what you
want.
In a way this is a special
Devin Jeanpierre added the comment:
I think they misspoke, it's normal with fuzzing to test against master. The
current draft of the code runs this git pull before building/launching any
tests:
git clone --depth 1 https://github.com/python/cpython.git cpython
Speaking of which, I forgot
Changes by Devin Jeanpierre <jeanpierr...@gmail.com>:
--
pull_requests: +2929
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Devin Jeanpierre added the comment:
Aha, I found an existing issue!
For adding to oss-fuzz, is there a contact email we can use that is connected
to a google account? I am tempted to just put gregory.p.smith on there if not.
:)
I can volunteer to fuzz some interesting subset of the stdlib
Devin Jeanpierre added the comment:
https://github.com/google/oss-fuzz/pull/583 is the PR to oss-fuzz to add the
project. I'm working on actual tests to be submitted here.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Devin Jeanpierre added the comment:
> Write your own C extension to do that. Sorry, I don't know what is the best
> way to write such C extension.
If everyone who wants to convert intptr_t to a python int has to write their
own function, then why not just include it in the C-API?
Devin Jeanpierre added the comment:
> Devin, I asked you for a strong rationale to add the feature. I don't see
> such rationale, so this issue will be closed again.
I guess we have different definitions of "strong rationale". Clearer criteria
would help.
>> It
Devin Jeanpierre added the comment:
> Making two C functions public is very different from supporting intmax_t. I
> expect a change of a few lines, whereas my intmax_t patch modified a lot of
> code.
I requested either a way to create from intmax_t, or from bytes. We have two
Devin Jeanpierre added the comment:
Oh, to be clear on this last point:
> Hum, who else needs such function except of you?
Right now there is no way to convert an int that might be > 64 bits, into a
python long, except really bizarre shenanigans, unless we want to rely on
implemen
Devin Jeanpierre added the comment:
> I wrote my first patch in 2013, but I still fail to find a very good example
> where intmax_t would be an obvious choice. So I have to agree and I will now
> close the issue.
Hold on, nobody ever answered the question in the OP. How would yo
Devin Jeanpierre added the comment:
Oops, so it is. I can't read apparently.
I'll spend my time on making more fuzz tests in the meantime.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Devin Jeanpierre added the comment:
So here's an interesting issue: oss-fuzz requires that the built location be
movable. IOW, we build Python into $OUT, and then the $OUT directory gets moved
somewhere else and the fuzz test gets run from there. This causes problems
because Python can
Changes by Devin Jeanpierre <jeanpierr...@gmail.com>:
--
pull_requests: +3412
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Devin Jeanpierre <jeanpierr...@gmail.com>:
--
keywords: +patch
pull_requests: +3434
stage: test needed -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Devin Jeanpierre added the comment:
Huh. I would not have predicted that.
https://gcc.gnu.org/onlinedocs/cpp/Defined.html
I'll send a fix.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Devin Jeanpierre added the comment:
> i'd rather make this work in oss-fuzz on cpython. can you point me to how
> oss-fuzz works and what it wants to do so i can better understand what it
> needs?
I don't have any details except for what's in the PR to oss-fuzz
(https://github.c
Devin Jeanpierre added the comment:
kcc strongly disagrees though. Copying latest comment:
"""
fwiw - I object to us running any of this internally at Google. We need to be
part of the main oss-fuzz project pulling from upstream revisions. Doing this
testing within our blackh
Change by Devin Jeanpierre :
--
keywords: +patch
pull_requests: +19700
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20444
___
Python tracker
<https://bugs.python.org/issu
New submission from Devin Jeanpierre :
`hmac.compare_digest` (via `_tscmp`) does not mark the accumulator variable
`result` as volatile, which means that the compiler is allowed to short-circuit
the comparison loop as long as it still reads from both strings.
In particular, when `result
96 matches
Mail list logo
