Armin Rigo added the comment:
I won't try to influence the outcome of this discussion, but I'd like to
correct myself: in the measures I posted, "true randomness" is not needed at
all. The exact criterion might be hard to pin down, but as a first
approximation, we get
Armin Rigo added the comment:
Wrong, sorry. On a 32-bit Python 2.7, "(2**32-1)*n" has the same hash -2, for
any value of n.
Of course if you build a dict containing thousands of such integers as keys,
then right now you get unexpectedly bad performance. I wonder if I should ope
New submission from Armin Rigo:
ctypes pretends to support passing arguments to C functions that are unions
(not pointers to unions), but that's a lie. In fact, the underlying libffi
does not support it. The attached example misbehaves on Linux x86-64.
--
components: ctypes
Changes by Armin Rigo :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue16575>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Armin Rigo:
ctypes pretends to support passing arguments to C functions that are structures
containing bitfields, or at least does not explicitly forbid it. But doing so
results in misbehavior or segfaults in libffi itself. Indeed, libffi has no
support for this, and
Armin Rigo added the comment:
The same misbehavior occurs if the structures are packed ("_pack_ = 1").
Attached in test186_lib.tgz.
--
Added file: http://bugs.python.org/file28157/test186_lib.tgz
___
Python tracker
<http://bu
Armin Rigo added the comment:
FWIW, on Windows only, "open('foo', 'a').tell()" always returns 0, which I
think is broken too. It usually works anyway, because it updates the position
before the first .write(). But it does not work in case the writing oc
New submission from Armin Rigo:
The docstring of thread.lock.acquire() (or _thread on Python 3) is bogus: it
says that if called without argument, the return value is None; it is only if
called with a "blocking" argument that it returns True or False. But since a
long time it
New submission from Armin Rigo:
It is possible to get the working copy of Python 2.7 in a state such that any
attempt to do "make" ends with the error shown in the title. The working copy
is perfectly valid; it is a matter of getting the wrong timestamps on the files.
(Despite
New submission from Armin Rigo:
The attached patch (which can be applied on both trunk and 2.7) gives a huge
speed improvement for the case 'pow(huge_number, smallish_number,
smallish_number)'. The improvement is unbounded: I get 20x with 'pow(x, y, z)'
with the argument
Armin Rigo added the comment:
Better remove this field if its value is now useless anyway. If someone needs
it again for a similar reason, he can contribute a patch like I did in 2002 :-)
--
___
Python tracker
<http://bugs.python.org/issue19
Armin Rigo added the comment:
Another option for the "try harder to raise RuntimeError" category (which I
tend to like, because otherwise people are bound to write programs that rely on
undocumented details):
In __delitem__() set link.next = None. In the various iterators check
Armin Rigo added the comment:
Modifying an ordered dict while iterating over it can be officially classified
as an ok think to do, but then the precise behavior must described in the
documentation in some details, with of course matching implementation(s) and
tests. I mean by that that the
Armin Rigo added the comment:
Hi Raymond! Yes, I had the same reaction at first, but then it seemed to be
possible to implement a reasonably good behavior with almost no performance hit.
Plainly undefined behaviors are a mess for other implementations because in
half of the big projects
Armin Rigo added the comment:
'list' doesn't, precisely.
--
___
Python tracker
<http://bugs.python.org/issue19414>
___
___
Python-bugs-list mai
New submission from Armin Rigo:
WeakValueDictionary.setdefault() contains a bug that shows up in multithreaded
situations using reference cycles. Attached a test case: it is possible for
'setdefault(key, default)' to return None, although None is never put as a
value in the
Changes by Armin Rigo :
Added file: http://bugs.python.org/file32557/x.py
___
Python tracker
<http://bugs.python.org/issue19542>
___
___
Python-bugs-list mailin
Changes by Armin Rigo :
Added file: http://bugs.python.org/file32558/weakref.slice
___
Python tracker
<http://bugs.python.org/issue19542>
___
___
Python-bugs-list mailin
Armin Rigo added the comment:
Am I correct in thinking that you're simply replacing the OSError(EINTR) with
returning empty lists? This is bound to subtly break code, e.g. the code that
expects reasonably that a return value of three empty lists means the timeout
really ran out (i.e
Armin Rigo added the comment:
Modules/socketmodule.c is using a simple style to implement socket timeouts
using select(). If I were to naively copy this style over to pure Python, it
would work in current Pythons; I'd get occasionally an OSError(EINTR), which I
would have presumably
Armin Rigo added the comment:
As you can see in x.py, the underlying question is rather: are weakdicts usable
in a single thread of a multithreaded program? I believe that this question
cannot reasonably be answered No, independently on the answer you want to give
to your own question
Armin Rigo added the comment:
The opposite argument might be relevant too: in some cases, a tracing JIT
compiler seeing a long block of code might perform artificially worse. If each
repeated line creates a branching path with two outcomes of roughly equal
likeliness, then if the line is
Armin Rigo added the comment:
...but I don't think PyPy should be by itself a good enough reason to reject
this patch. It would be fine if timeit detects which interpreter it runs on,
and only tries to unroll on CPython, for example.
--
___
P
New submission from Armin Rigo:
The documentation of the built-in compile() function is not 100% clear but I
think it says that giving the "optimize=1" argument turns "__debug__" to false
in the compiled code (
https://docs.python.org/3.5/library/functions.html?highl
Armin Rigo added the comment:
It was clear to me four years ago. Now I'd have to dig again as much as you do.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Armin Rigo:
Calling Python 2.7's new version of ntpath.splitdrive() with argument either
'//' or r'\\' results in an IndexError: string index out of range.
--
messages: 226163
nosy: arigo
priority: normal
severity: normal
status: open
Armin Rigo added the comment:
For completeness:
Python 2.7.6: ntpath.splitdrive('//') => ('', '//')
Python 2.7.8: ntpath.splitdrive('//') => IndexError
--
___
Pyth
New submission from Armin Rigo:
$ LINES=20 python Lib/test/test_pydoc.py
...
File ".../Lib/pydoc.py", line 1448, in ttypager
r = inc = os.environ.get('LINES', 25) - 1
TypeError: unsupported operand type(s) for -: 'str' and 'int'
duh.
--
co
Armin Rigo added the comment:
In my own case I use os.popen("wget ...") instead of urllib2 just because some
version long ago failed on some web site. I can trust that this external tool
works all the time. It would be great if urllib2 worked as well nowadays.
So my opinion on
New submission from Armin Rigo:
This is a repeat of the old issue 532860: "NameError assigning to class in a
func". It is about class statements' variable lookups, which has different
behavior at module level or in a nested scope:
def f(n):
class A:
n = n
New submission from Armin Rigo:
This is probably the smallest example of a .py file that behaves differently in
CPython vs PyPy, and for once, I'd argue that the CPython behavior is
unexpected:
# make the file:
>>> open('x.py', 'wb').write('
Armin Rigo added the comment:
Fwiw, both exec and eval() ban NUL bytes, which means that there is a strange
case in which some files can be imported, but not loaded and exec'ed. So I
agree with Benjamin.
--
___
Python tracker
Armin Rigo added the comment:
PyPy 2.x accepts null characters in all of import, exec and eval, and complains
if they occur in non-comment.
PyPy 3.x refuses them in import, which is where this bug report originally
comes from (someone complained that CPython 3.x "accepts" them but n
Armin Rigo added the comment:
Instances of 'staticmethod' or 'classmethod' are not callable. I'm unsure why
not, but it's good enough, as you need to go through various unexpected hops in
order to try to call one.
'dict.fromkeys' is not a classmet
Armin Rigo added the comment:
Hi Fabio! This is admittedly a corner-case use case, but if you think it would
be worth it, we can very easily add this as a feature to PyPy (by making
frame.f_locals writeable). Then we can add the write inside pdb, and you could
do the same for PyDev when
Armin Rigo added the comment:
Also, can you provide a concrete case? Trying around in CPython 2.7, it seems
that locals of the current frame can always be modified from a pdb.set_trace().
--
___
Python tracker
<http://bugs.python.org/issue1654
Armin Rigo added the comment:
Sorry to hijack CPython's bug tracker for that, but can you check if this makes
sense to you? I added a function 'locals_to_fast()' to the __pypy__ built-in
module which just calls the PyPy equivalent to PyFrame_LocalsToFast(). Your
tests ar
Armin Rigo added the comment:
CPython 2.7 is in feature-freeze, so we need to add it to __pypy__. If people
here decide to add it more officially to CPython 3.x, then we'll also add it
into pypy3, obviously. I'm sure a debugger can cope with a few extra ifs to
check on which plat
Changes by Armin Rigo :
--
assignee: arigo ->
___
Python tracker
<http://bugs.python.org/issue1617161>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Armin Rigo :
The __str__ method of some exception classes reads attributes without
typechecking them. Alternatively, the issue could be that the user is
allowed to set the value of these attributes directly, without
typecheck. The typechecking is only done when we create
New submission from Armin Rigo :
The re module is buggy is rare cases; see attached example script.
The bug is caused by the macros LASTMARK_SAVE and LASTMARK_RESTORE which are
sometimes used without the extra code that does if (state->repeat)
{mark_save()/mark_restore()}.
The bug appears
Armin Rigo added the comment:
It's pretty trivial to turn my x.py into a unit test, of course.
--
___
Python tracker
<http://bugs.python.org/issue9134>
___
___
Armin Rigo added the comment:
I reviewed your patch again. It does look good after all: I find only one
issue---it seems I implied there were several ones but I can't find more. The
issue is that PyString_AsString(result) will succeed if 'result' is a unicode.
Armin Rigo added the comment:
Looks ok now!
--
___
Python tracker
<http://bugs.python.org/issue11145>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
issue28427-atomic.patch: is it still necessary to modify weakref.py so much,
then?
What I had in mind was a C function with Python signature "del_if_equal(dict,
key, value)"; the C function doesn't need to know about weakrefs and checking
if they
Armin Rigo added the comment:
I think the issue of __len__() is a different matter. More below.
>> The C function would simply call PyObject_GetItem() and
>> PyObject_DelItem()---without releasing the GIL in the middle.
>
> If you implement it like that, and the dictiona
Armin Rigo added the comment:
Agreed about fixing the other issues. I'm still unclear that we need anything
more than just the _remove_dead_weakref function to do that, but also, I don't
see a particular problem with adding self._commit_removals() a bit everywhere.
About the O(1) e
Armin Rigo added the comment:
os.scandir() returns an iterable object that should not be used
from multiple threads. Doing so can e.g. cause one thread to
close the dirp while another thread is still using it. This is
likely to crash. Similarly, the test for (!iterator->dirp) at
Armin Rigo added the comment:
(C2) os.scandir() direntry objects should not have stat() called from two
threads concurrently. It will make two stat objects and leak one of
them.
--
___
Python tracker
<http://bugs.python.org/issue28
Armin Rigo added the comment:
(C3) _PyGen_yf() checks the opcode at [f_lasti + 1], which is the next
opcode that will run when we resume the generator: either it is the
opcode following the YIELD, or it is exactly YIELD_FROM. It is not
possible at the moment to write Python code that
Armin Rigo added the comment:
(C6) I didn't try, but it seems that typeobject.c:mro_internal() is prone
to a refcount crash. It does this::
old_mro = type->tp_mro;
...mro_invoke()... /* might cause reentrance */
type->tp_mro = new_mro;
...
Py_XDEC
New submission from Armin Rigo:
As discussed on python-dev, I am creating omnibus issues from the lists of
crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues
that I found while developing Python 3.5.2 support for PyPy. These occur with
CPython 3.5.2 but most of
Armin Rigo added the comment:
(C4) faulthandler: register(): the signal handler, faulthandler_user(),
changes errno in faulthandler_dump_traceback() but fails to restore it
if chain=False. This can rarely cause random nonsense in the main
program
Armin Rigo added the comment:
(C5) setting f_lineno didn't evolve when the rest of the bytecodes evolved,
which means it is not safe any more::
import sys
def f():
try:
raise ValueError# line 5
except ValueError:
print(42) #
New submission from Armin Rigo:
As discussed on python-dev, I am creating omnibus issues from the lists of
crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues
that I found while developing Python 3.5.2 support for PyPy. These occur with
CPython 3.5.2 but most of
Armin Rigo added the comment:
(C6) I didn't try, but it seems that typeobject.c:mro_internal() is prone
to a refcount crash. It does this::
old_mro = type->tp_mro;
...mro_invoke()... /* might cause reentrance */
type->tp_mro = new_mro;
...
Py_XDEC
Armin Rigo added the comment:
(B1) on modern Linux: if the first call in the process to
socketpair() ends in a EINVAL, then cpython will (possibly wrongly)
assume it was caused by SOCK_CLOEXEC and not use SOCK_CLOEXEC at all
in the future
Armin Rigo added the comment:
(B3) re.sub(b'y', bytearray(b'a'), bytearray(b'xyz')) -> b'xaz'
re.sub(b'y', bytearray(b'\\n'), bytearray(b'xyz')) -> internal TypeError
--
__
Changes by Armin Rigo :
--
Removed message: http://bugs.python.org/msg282524
___
Python tracker
<http://bugs.python.org/issue28883>
___
___
Python-bugs-list mailin
Armin Rigo added the comment:
(B2) fcntl.ioctl(x, y, buf, mutate_flag): mutate_flag is there for the case
of buf being a read-write buffer, which is then mutated in-place.
But if we call with a read-only buffer, mutate_flag is ignored (instead
of rejecting a True value)---ioctl(x, y, &quo
Armin Rigo added the comment:
(B4) if you have a stack of generators where each is in 'yield from' from
the next one, and you call '.next()' on the outermost, then it enters
and leaves all intermediate frames. This is costly but may be
required to get the sys.settrace(
Armin Rigo added the comment:
(B5) this is an old issue that was forgotten twice on the
issue tracker: ``class C: __new__=int.__new__`` and ``class C(int):
__new__=object.__new__`` can each be instantiated, even though they
shouldn't. This is because ``__new__`` is completely ignor
Armin Rigo added the comment:
(B6) this program fails the check for no sys.exc_info(), even though at
the point this assert runs (called from the <== line) we are not in
any except/finally block. This is a generalization of
test_exceptions:test_generator_doesnt_retain_old_
Armin Rigo added the comment:
(B7) frame.clear() does not clear f_locals, unlike what a test says
(Lib/test/test_frame.py)::
def test_locals_clear_locals(self):
# Test f_locals before and after clear() (to exercise caching)
f, outer, inner = self.make_frames
Armin Rigo added the comment:
(B8) also discussed in connection with https://bugs.python.org/issue28427
weak dicts (both kinds) and weak sets have an implementation of
__len__ which doesn't give the "expected" result on PyPy, and in some
cases on CPython too. I
Armin Rigo added the comment:
(B9) CPython 3.5.2: this ``nonlocal`` seems not to have a reasonable
effect (note that if we use a different name instead of ``__class__``,
this example correctly complain that there is no binding in the outer
scope of ``Y``)::
class Y:
class X
Armin Rigo added the comment:
(B10) Follow-up on issue #25388: running ``python x.py`` if x.py contains
the following bytes...
* ``b"#\xfd\n"`` => we get a SyntaxError: Non-UTF-8 code
* ``b"# coding: utf-8\n#\xfd\n&quo
Armin Rigo added the comment:
(S4) if you write ``from .a import b`` inside the Python prompt, or in
a module not in any package, then you get a SystemError(!) with an
error message that is unlikely to help newcomers.
--
___
Python tracker
<h
New submission from Armin Rigo:
As discussed on python-dev, I am creating omnibus issues from the lists of
crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues
that I found while developing Python 3.5.2 support for PyPy. These occur with
CPython 3.5.2 but most of
Armin Rigo added the comment:
(S3) hash({}.values()) works (but hash({}.keys()) correctly gives
TypeError). That's a bit confusing and, as far as I can tell, always
pointless. Also, related: d.keys()==d.keys() but
d.values()!=d.v
Armin Rigo added the comment:
(S1) ceval.c: GET_AITER: calls _PyCoro_GetAwaitableIter(), which might
get an exception from calling the user-defined __await__() or checking
what it returns; such an exception is completely eaten.
--
___
Python
Armin Rigo added the comment:
(S2) argument clinic turns the "bool" specifier into
PyObject_IsTrue(), accepting any argument whatsoever. This can easily
get very confusing for the user, e.g. after messing up the number of
arguments. For example: os.symlink("/path1"
Armin Rigo added the comment:
(S5) pep 475: unclear why 'os.fchmod(fd)' retries automatically when
it gets EINTR but the otherwise-equivalent 'os.chmod(fd)' does not.
(The documentation says they are fully equivalent, s
Changes by Armin Rigo :
--
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue28885>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Rigo :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue28884>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Armin Rigo :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue28885>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Armin Rigo :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue28883>
___
___
Python-bugs-list mailing list
Unsubscrib
Armin Rigo added the comment:
(S5) gregory: actually there is also fchown/chown in the same situation.
--
___
Python tracker
<http://bugs.python.org/issue28
New submission from Armin Rigo:
2.7.13 did a small change to the sqlite commit() method,
http://bugs.python.org/issue10513, which I think is causing troubles. I
noticed the problem in PyPy, which (with the same change) fails another test in
Lib/sqlite3/test/regression.py, CheckTypeMapUsage
Armin Rigo added the comment:
Or maybe it would be enough to change commit() so that if Sqlite fails with
"table is locked", pysqlite would reset all cursors and then try again?
--
___
Python tracker
<http://bugs.python.o
Armin Rigo added the comment:
Tried that, but reverted because on Windows CheckTypeMapUsage() would fail with
SQLITE_MISUSE ("ProgrammingError: database table is locked"). For now PyPy
will not implement this 2.7.13 change. I really suspect you can get the same
problems on CPyth
Armin Rigo added the comment:
The signal handler is called between the INPLACE_ADD and the following
STORE_FAST opcode, never from string_concatenate() itself. A fix would be to
make sure signal handlers are not called between these two opcodes. See the
minimal, proof-of-concept patch #1
Changes by Armin Rigo :
Added file: http://bugs.python.org/file46151/patch2.diff
___
Python tracker
<http://bugs.python.org/issue29096>
___
___
Python-bugs-list mailin
Changes by Armin Rigo :
Removed file: http://bugs.python.org/file46150/patch1.diff
___
Python tracker
<http://bugs.python.org/issue29096>
___
___
Python-bugs-list mailin
Changes by Armin Rigo :
Added file: http://bugs.python.org/file46153/patch1.diff
___
Python tracker
<http://bugs.python.org/issue29096>
___
___
Python-bugs-list mailin
Armin Rigo added the comment:
(S6) 'xxx' % b'foo' == 'xxx'
b'xxx' % b'foo' raises TypeError
The first case is because PyMapping_Check() is true on b'foo', so it works like
'xxx' % {...}, which always just returns '
Armin Rigo added the comment:
> Armin, it would help if you report all cases as separate issues.
I asked on python-dev before creating these three issues, and got the opposite
answer. If you decide it was a bad idea after all, I will open separate issues
in the fut
Armin Rigo added the comment:
If I had a say, I would indeed revert 030e100f048a (2.7 branch) and
81f614dd8136 (3.5 branch) as well as forward-port the revert to 3.6 and trunk.
Then we wait for someone that really knows why the change was done in the first
place
Armin Rigo added the comment:
Gian-Carlo is right: I can modify the 2.6 tests in the same way as I described,
and then I get the same error with python2.6. So it seems that all of 2.6 was
prone to the same issue, and it was never found, but went away in 2.7
accidentally. That seems to mean
Armin Rigo added the comment:
...hah, of course the commit dd13098a5dc2 also reverted away the new test.
That test fails. Sorry about that, and feel free to redo that commit. It's
just one more case in which the implicit refcounting is used, but I guess as it
fixes a real issue it
Armin Rigo added the comment:
Managed to write a patch in PyPy that seems to pass all tests including the new
one, including on Windows. I know think that dd13098a5dc2 should be backed out
(i.e. 030e100f048a should be kept).
Reference to the PyPy changes:
https://bitbucket.org/pypy/pypy
Armin Rigo added the comment:
larry: unless someone else comments, I think now that the current status of
3.5.3 is fine enough (nothing was done in this branch, and the problem I
describe and just fixed in PyPy can be left for later).
The revert dd13098a5dc2 needs to be itself reverted in the
Armin Rigo added the comment:
Confirmed. More interestingly, nowadays (at least in 3.5) test_pdb.py depends
on this bug. If we really clear f->f_trace when the trace function returns
None, then test_pdb_until_command_for_generator() fails. This is because
pdb.py incorrectly thinks there
Armin Rigo added the comment:
Just to add my comment to this 7-years-old never-resolved issue: in PyPy 3.5,
which behaves like Python 3.x in this respect, I made the following
constructions give a warning.
def wrong_listcomp():
return [(yield 42) for i in j]
def wrong_gencomp
Armin Rigo added the comment:
Let's see if the discussion goes anywhere or if this issue remains in limbo for
the next 7 years. In the meantime, if I may humbly make a suggestion: whether
the final decision is to give SyntaxError or change the semantics, one or a few
intermediate ver
Armin Rigo added the comment:
* Tom: the issue is unrelated to cffi, but both ctypes and cffi could proceed
to support C complexes, now that libffi support has been added.
* Mark: the problem is that the text you quote from the C standard fixes the
representation of a complex in memory, but
New submission from Armin Rigo:
A difference in behavior between _decimal and _pydecimal (it seems that
_decimal is more consistent in this case):
class X(Decimal):
def __init__(self, a):
print('__init__:', a)
X.from_float(42.5) # __init__: Dec
New submission from Armin Rigo:
The documentation on the hash randomization says that date, time and datetime
have a hash based on strings, that is therefore nondeterministic in several
runs of Python. I may either be missing a caveat, or the actual implementation
does not follow its promise
Armin Rigo added the comment:
That's not what the docs say. E.g.:
https://docs.python.org/3/reference/datamodel.html#object.__hash__ says
By default, the __hash__() values of str, bytes and datetime objects are
“salted” with an unpredictable random value. Although they remain con
Armin Rigo added the comment:
Sorry! It should be repr(a) inside the print. Here is the fixed version:
class X(Decimal):
def __init__(self, a):
print('__init__:', repr(a))
X.from_float(42.5) # __init__: Decimal('42.5')
X.from_float(42)
201 - 300 of 384 matches
Mail list logo
