Armin Rigo added the comment:
CPython 2.7 and 3.5 have issues with the sign of zeroes even without any custom
class:
>>> -(0j) # this is -(0+0j)
(-0-0j)
>>> (-0-0j) # but this equals to the difference between 0 and 0+0j
0j
>>> (-0.0-0j) # this is the di
Armin Rigo added the comment:
Maybe I should be more explicit: what seems strange to me is that some complex
numbers have a repr that, when entered in the source, produces a different
result. For example, if you want the result ``(-0-0j)`` you have to enter
something different. However, I
Armin Rigo added the comment:
4 lines before the new "ci.real = cr.imag;", we have "cr.imag = 0.0; /* Shut up
compiler warning */". The comment is now wrong: we really need to set cr.imag
to 0.0.
--
___
Python tracker
<
New submission from Armin Rigo:
In Python 2.7, PC/msvcrtmodule.c, the function msvcrt_ungetwch() calls
_ungetch() instead of _ungetwch() as was probably intended.
--
components: Extension Modules
messages: 270620
nosy: arigo
priority: normal
severity: normal
status: open
title
Armin Rigo added the comment:
Uh, you're right. Then I can also add that putwch() strangely checks for
unicode strings of length != 0 instead of == 1, despite what it says it its
error message. These functions appear not to be tested or even (in case of
ungetwch()) used by a
Armin Rigo added the comment:
Can we make the exit message optional? Otherwise PyPy will need to patch
code.py to add the option to not display this message when used as the normal
REPL (yes, PyPy uses the plain code.py as its built-in REPL).
--
nosy: +arigo
Armin Rigo added the comment:
I'm fine with `exitmsg`. I guess it would be a flag (not `None` as you wrote),
defaulting to `True`?
--
___
Python tracker
<http://bugs.python.org/is
Armin Rigo added the comment:
...ah, upon closer inspection, we don't use the ``interact()`` method anyway.
We already copied and tweaked this method: one problem was that it gives no way
to run without printing at least one '\n' of banner at the beginning. Then a
more impo
New submission from Armin Rigo:
_PyGen_Finalize() should not fail with an exception. Doing so can cause
various SystemErrors or even fatal errors. For example, run this with "python
-Werror":
import gc
async def f():
pass
f()
gc.collect() # RuntimeWarning
New submission from Armin Rigo:
PyFrameObject.f_gen is a pointer (not a reference) to a generator/coroutine
object. But the latter doesn't always correctly clean it up when it dies.
This pointer is used by frame.clear().
Here is an example I made, which ends in a segfault. This ex
Armin Rigo added the comment:
See also http://bugs.python.org/issue16576.
--
___
Python tracker
<http://bugs.python.org/issue16575>
___
___
Python-bugs-list mailin
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue1173475>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Armin Rigo:
Run this example on a 32-bit machine with more than 2GB of addressable RAM
(e.g. by default, more or less anything but Windows).
On Python 2.7 it raises "SystemError: Negative size passed to
PyString_FromStringAndSize". On a debug version, it causes
Changes by Armin Rigo :
--
components: +Interpreter Core
type: -> crash
___
Python tracker
<http://bugs.python.org/issue17645>
___
___
Python-bugs-list mai
Armin Rigo added the comment:
Modified the example to run in only 1+GB of RAM, so that it crashes also on
32-bit versions of the Python 2.7 interpreter in Windows (the most common
around, I suppose).
--
Added file: http://bugs.python.org/file29689/mem2x.py
Armin Rigo added the comment:
You may want to add a test. This might help notice that comparing an integer
of type Py_ssize_t to check if it's greater than PY_SSIZE_T_MAX is bogus in C
:-(
--
resolution: fixed ->
stage: committed/rejected ->
Armin Rigo added the comment:
Uh, confusion. Indeed, "PATH= foo" finds foo in the current directory on bash.
I'm not sure how I ran the original example. It seems that a default PATH is
used, which includes at least "/bin" and ".".
The point I was making
Armin Rigo added the comment:
Grrr, ok, I have an "alias ls='/bin/ls'". It seems that both "PATH=" and
"unset PATH" are equivalent to "PATH=.". This is behavior that we cannot add
to PYTHONPATH, I fear, because so far "." is not
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue16273>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Armin Rigo:
In Python 2, a buffered file opened for writing is flushed by the C library
when the process exit. In Python 3, the _pyio and _io modules don't do it
reliably. They rely on __del__ being called, which is not neccesarily the
case. The attached example
Armin Rigo added the comment:
It used to be a consistently reliable behavior in Python 2 (and we made it so
in PyPy too), provided of course that the process exits normally; but it no
longer is in Python 3. Well I can see the reasons for not flushing files, if
it's clearly docum
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue1545463>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
Well, adding weak references left and right to break cycles is going to subtly
change or break people's code and hasn't been done so far, but that's only my
opinion. Anyway, I want to correct what you say about tp_subclasses: yes,
tp_subclass
Armin Rigo added the comment:
Can someone confirm the answer to Arfrever's original question: a seemingly
innocent use case of py_compile.compile(), which works fine until Python 3.3,
when executed as root, can in Python 3.4 fundamentally break down a complete
Posix system in a non-ob
Armin Rigo added the comment:
My point is that in five years' time some existing well-tested sysadmin-like
program will be run with Python 3.4 for the first time, and suddenly whole
systems will break. I don't want to sound negative but this is the worst
behavior ever (with th
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue18004>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
It's seriously obscure to call a user-defined __oct__ method and then mangle
the resulting string in ways that only make sense if the __oct__ method
returned something reasonable.
The patch is probably a little more complicated than it could be. For exampl
Armin Rigo added the comment:
+if (Py_REFCNT(result) == 1)
+buf[len] = '\0';
...and if the refcount is not equal to 1, then too bad, we won't null-terminate
the string and hope that nobody crashes
Armin Rigo added the comment:
Ah, sorry. Ok. Now a different issue: the user-defined function can return an
interned string. If it has a refcount of 1, _PyString_FormatLong() will mutate
it. Then when we DECREF it, string_dealloc() will not find it any more in the
interned dict and crash
Armin Rigo added the comment:
If buf contains "-00" and the type is 'o', then it will be modified in-place
even if the string is shared.
--
___
Python tracker
<http://bug
Armin Rigo added the comment:
Victor: there is the GIL, you don't need any locking.
--
___
Python tracker
<http://bugs.python.org/issue17852>
___
___
Pytho
Armin Rigo added the comment:
I hate to repeat myself, but if the C standard says "files are flushed at
exit"; if Python 2 follows this standard; and if Python 3 follows it most of
the time but *not always*... then it seems to me that something is very, very
buggy in the worst po
Armin Rigo added the comment:
If I understood correctly, Python 3.4 tries harder to find cycles and call
destructors at the end of the program, but that's not a full guarantee. For
example you can have a reference from a random C extension module.
While trying to come up with an examp
Armin Rigo added the comment:
(Ah, it's probably a reference from the trace function -> func_globals -> f).
--
___
Python tracker
<http://bugs.python.
Armin Rigo added the comment:
To add to the confusion: Antoine's example produces an empty file on the
current trunk cd282dd0cfe8. When I first tried it on a slightly older trunk
(157 changesets ago), it correctly emitted a file with "barXXX ", but only if
"gc.co
Armin Rigo added the comment:
Maybe accepting the fact that relying on finalizers is a bad idea here?
--
___
Python tracker
<http://bugs.python.org/issue17
Armin Rigo added the comment:
Antoine: sorry if I wasn't clear enough. Obviously you want to encourage
people to close their files, but I think personally that it is very bad for the
implementation to *most of the time* work anyway and only rarely fail to flush
the files. So, speaking
Armin Rigo added the comment:
Antoine: I'm trying to explain what in the three lines that follow the parts
you quoted. I already tried to explain it a few times above. Now I feel that
I'm not going anywhere, so I'll quote back myself from 2013-04-27: "Feel free
to close
Armin Rigo added the comment:
Here is a proof-of-concept. It changes both _pyio.py and bufferedio.c and was
tested with the examples here. (See what I meant with "linked lists".) The
change in textio.c is still missing, but should be very similar to
bufferedio.c. This is simi
Changes by Armin Rigo :
--
keywords: +patch
Added file: http://bugs.python.org/file37359/pyio.diff
___
Python tracker
<http://bugs.python.org/issue17852>
___
___
New submission from Armin Rigo:
It's not possible to write a settrace() or setprofile() function that remains
active if we're about to run out of stack. If we are, we get a RuntimeError
when the function is called. The RuntimeError is normally propagated, but in
case it is eaten
Armin Rigo added the comment:
Sorry, your patch still contains similar issues. I postponed continuing to
bounce it back and forth, but it seems that someone else needs to take my place
now.
--
___
Python tracker
<http://bugs.python.org/issue11
Changes by Armin Rigo :
--
keywords: +patch
Added file: http://bugs.python.org/file37992/fix-weakvaluedict.diff
___
Python tracker
<http://bugs.python.org/issue19
Changes by Armin Rigo :
Added file: http://bugs.python.org/file37993/fix-weakvaluedict-2.7.diff
___
Python tracker
<http://bugs.python.org/issue19542>
___
___
Python-bug
Armin Rigo added the comment:
Converted the test into an official test, which fails; and wrote the patch for
CPython "3.trunk" and for CPython 2.7. Please review and commit.
--
keywords: +needs review -patch
stage: needs patch ->
New submission from Armin Rigo:
In the interactive prompt:
>>> if 1:
...
Pressing tab here should just insert 4 spaces. It makes no sense to display all
500 possible "completions" of the empty word, and using tab to indent is a very
common feature of any editor with a
Armin Rigo added the comment:
Ah, thanks, I missed there was already an issue.
The patch's logic is as follows: when pressing tab anywhere in the line, if the
word to complete is empty (which might be for any number of reasons, like the
cursor is after another space or a non-word char
New submission from Armin Rigo:
The computation of `co_stacksize' by the compiler is known to give only an
upper bound estimate. http://bugs.python.org/issue1754094 is an example of
fixing a "leak" where every repetition of a statement makes `co_stacksize'
bigger by 1. H
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue24340>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
No problem from PyPy.
--
___
Python tracker
<http://bugs.python.org/issue24450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
Related to http://bugs.python.org/issue19979 and others mentioned there.
--
nosy: +arigo
___
Python tracker
<http://bugs.python.org/issue24
New submission from Armin Rigo:
A regression in 3.5: if we use custom objects as modules (like some projects
do), then these custom objects may not have an attribute called "__name__".
There is new code in 3.5 added for issue #17636 which tries sometimes to read
the "__name
Changes by Armin Rigo :
Added file: http://bugs.python.org/file39791/test_case.py
___
Python tracker
<http://bugs.python.org/issue24492>
___
___
Python-bugs-list mailin
Armin Rigo added the comment:
I'd guess so: if the PyObject_GetAttrId() fails, then ignore the rest of the
code that was added in https://hg.python.org/cpython/rev/fded07a2d616 and jump
straight to ``PyErr_Format(PyExc_Import
Armin Rigo added the comment:
Also, if we want to be paranoid, the _PyObject_GetAttrId() can return anything,
not necessarily a string object. This would make the following
PyUnicode_FromFormat() fail. So maybe you also want to overwrite failures in
PyUnicode_FromFormat() with the final
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue24450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
FWIW ``bool(Null())`` gives "correctly" the result False in CPython 3.5.
The problem in my opinion is that "!Py_TPFLAGS_BASETYPE" is checked only on the
best base instead of on all bases. It lets this kind of nonsense pass through.
In CPyt
Armin Rigo added the comment:
@brechtm No, the example you give is wrong. It is correct that this refuses to
work (and unrelated to this bug):
class Integer(object, int): pass
for reasons explained in the docs.
--
___
Python tracker
<h
Armin Rigo added the comment:
To be clearer, this bug report is, more precisely, about subclassing built-in
classes that are not meant to be subclassable. This includes type(None) and
bool.
--
___
Python tracker
<http://bugs.python.org/issue24
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue24806>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
Patch LGTM too. Optionally a test is needed for each of the other cases in it
too, but please don't cause that comment to stop it from getting in.
--
___
Python tracker
<http://bugs.python.org/is
Armin Rigo added the comment:
Roman: bz2.decompress(comp.read()) returns a string, so you can't use "with" on
it. This bug was about using "with bz2.BZ2File(...) as f:".
--
___
Python tracker
<http
New submission from Armin Rigo:
Ctypes uses libffi's `ffi_closure_alloc()`, which has a bug that make existing
applications obscurely crash in one situation: if we are running on SELinux,
making use of callbacks, and forking. This is because `ffi_closure_alloc()`
will detect that
New submission from Armin Rigo:
itertools.accumulate() has got methods __reduce__() and __setstate__() which
fail at saving/restoring the state in all cases. Example:
>>> a = itertools.accumulate([0.0, 42])
>>> next(a)
0.0
>>> b = copy.deepcop
Armin Rigo added the comment:
Ok, then with pickle you can have the same problem but only with
None-vs-no-total. Here is an artificial example:
import itertools, pickle
def foo(a, b):
print(a, b)
a = itertools.accumulate([3, 4, 5], foo)
next(a)
next(a) # prints: 3, 4
b = pickle.loads
Armin Rigo added the comment:
This is a known general issue which is documented in
Lib/test/crashers/borrowed_ref_1 inside the 2.7 branch. In trunk, I see that
this file has been deleted, although the issue has not been solved in general.
Only the particular crash in the file has been
Armin Rigo added the comment:
PyWeakref_GET_OBJECT() is inherently dangerous: the weakref might go away not
only the next time the GIL is released, but also the next time the code does
any seemingly unrelated Py_DECREF() (which might decref the object into
inexistence) or memory allocation
Armin Rigo added the comment:
Actually, Py_DECREF() may also release the GIL by calling a Python __del__()
method; it doesn't have to directly decref the exact object.
--
___
Python tracker
<http://bugs.python.org/is
Armin Rigo added the comment:
Fwiw, I made a trivial benchmark in C that loads aligned and misaligned shorts
( http://paste.pound-python.org/show/HwnbCI3Pqsj8bx25Yfwp/ ). It shows that
the memcpy() version takes only 65% of the time taken by the two-bytes-loaded
version on a 2010 laptop. It
Armin Rigo added the comment:
(Typo: "only 45% faster" should be "only 45% of the time")
--
___
Python tracker
<http://bugs.python.org/issue25823>
___
_
Armin Rigo added the comment:
Other possible minimal fixes:
* compile.c:compiler_addop(): special-case code objects too, and stick their
identity in the tuple 't'.
* or, in compile.c:makecode(), append the first row number to
Armin Rigo added the comment:
That's what I suggested ("compile.c:compiler_addop(): special-case code objects
too, and stick their identity in the tuple 't'.") and how I fixed the same bug
in PyPy (https://bitbucket.org/pypy/
New submission from Armin Rigo:
There is an apparent inconsistency in unicodedata.normalize("NFC"), introduced
with the switch from the Unicode DB 5.1.0 to 5.2.0 (in Python 2.7). First,
please note that my knowledge of unicode is limited, so I may be wrong and the
following behavio
Armin Rigo added the comment:
Note: the examples can also be written in this clearer way on Python 3:
>>> from unicodedata import normalize
>>> print(ascii(normalize("NFC", "---\uafb8\u11a7---")))
'---\uafb8\u11a7---'
>>> p
Armin Rigo added the comment:
See also
https://bitbucket.org/pypy/pypy/issues/2289/incorrect-unicode-normalization .
It seems that you reached the same conclusion than the OP in that issue: the
problem would really be that normalizing "\uafb8\u11a7" should not drop the
second
Armin Rigo added the comment:
The PyArg_ParseTuple() size arguments should be of type "Py_ssize_t" instead of
"int".
--
nosy: +arigo
___
Python tracker
<http://bug
Armin Rigo added the comment:
Attached trivial example. This gives for me a bus error when run with selinux
(actually tested by changing the "return 0;" to "return 1;" in
selinux_enabled_check() file Modules/_ctypes/libffi/src/closures.c).
If you comment out any of the
Changes by Armin Rigo :
--
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python
3.6
___
Python tracker
<http://bugs.python.org/issue25
Armin Rigo added the comment:
For completeness:
* the crasher I attached gets a bus error even before calling
ffi_closure_free(). At that point, only ffi_closure_alloc() has been
called---in both parent and child.
* stricly speaking, cffi is not fixed: it has the same problem when
using
Armin Rigo added the comment:
You're welcome. Unrelated, but I'm collecting similar issues in a file at
http://bitbucket.org/pypy/extradoc/raw/extradoc/planning/py3.5/cpython-crashers.rst
. After reporting the first two, I stopped, and will report them all in bulk
some time late
New submission from Armin Rigo:
Follow-up on http://bugs.python.org/issue19542.
Another crash of using WeakValueDictionary() in a thread-local fashion inside a
multi-threaded program. I must admit I'm not exactly sure why this occurs, but
it is definitely showing an issue: two th
Armin Rigo added the comment:
I'll admit I don't know how to properly fix this issue. What I came up with so
far would need an atomic compare_and_delete operation on the dictionary
self.data, so that we can do atomically:
+elif self.data[wr.
Armin Rigo added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue19542>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Armin Rigo:
``python3.5 --help`` gives this information:
-u : unbuffered binary stdout and stderr, stdin always buffered
However, stdout and stderr are actually always opened in text mode, and print()
always expects a string and never a bytes object. This usage of
301 - 384 of 384 matches
Mail list logo
