[issue5322] object.__new__ argument calling autodetection faulty

Armin Ronacher added the comment: The bug is still there, just that it's now not just a warning but an error. The auto detection is incorrect here. It should allow the instantiation of the object with arguments. -- ___ Python tracker <ht

[issue45417] Enum creation non-linear in the number of values

Armin Rigo added the comment: The timing is clearly quadratic: number of attributes time 1500 0.24s 3000 0.94s 6000 3.74s 1200015.57s Pressing Ctrl-C in the middle of the execution of the largest examples

[issue38659] enum classes cause slow startup time

Armin Rigo added the comment: Nobody seemed to mention it so I might as well: defining a regular Enum class takes an amount of time that is clearly quadratic in the number of attributes. That means that the problem is not Python-versus-C or small speed-ups or adding secret APIs to do

[issue41097] confusing BufferError: Existing exports of data: object cannot be re-sized

Change by Armin Rigo : -- nosy: -arigo ___ Python tracker <https://bugs.python.org/issue41097> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41097] confusing BufferError: Existing exports of data: object cannot be re-sized

New submission from Armin Rigo : The behavior (tested in 3.6 and 3.9) of io.BytesIO().getbuffer() gives a unexpected exception message: >>> b = io.BytesIO() >>> b.write(b'abc') 3 >>> buf = b.getbuffer() >>> b.seek(0) 0 >>> b.write(b'?') # or

[issue38091] Import deadlock detection causes deadlock

Change by Armin Rigo : -- keywords: +patch pull_requests: +16996 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17518 ___ Python tracker <https://bugs.python.org/issu

[issue36229] Avoid unnecessary copies for list, set, and bytearray ops.

Change by Armin Rigo : -- nosy: -arigo ___ Python tracker <https://bugs.python.org/issue36229> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Armin Rigo added the comment: I agree with your analysis. I guess you (or someone) needs to write an explicit pull request, even if it just contains 187aa545165d cherry-picked. (I'm not a core dev any more nowadays) -- ___ Python tracker

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Armin Rigo added the comment: I may be wrong, but I believe that the bug requires using the C API (not just pure Python code). This is because Python-level lock objects have their own lifetime, and should never be freed while another thread is in PyThread_release_lock() with them

[issue29535] datetime hash is deterministic in some cases

Change by Armin Rigo : -- nosy: -arigo ___ Python tracker <https://bugs.python.org/issue29535> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34880] About the "assert" bytecode

Change by Armin Rigo : -- nosy: -arigo ___ Python tracker <https://bugs.python.org/issue34880> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7946] Convoy effect with I/O bound threads and New GIL

Armin Rigo added the comment: Note that PyPy has implemented a GIL which does not suffer from this problem, possibly using a simpler approach than the patches here do. The idea is described and implemented here: https://bitbucket.org/pypy/pypy/src/default/rpython/translator/c/src

[issue1875] "if 0: return" not raising SyntaxError

Change by Armin Rigo : -- nosy: -arigo ___ Python tracker <https://bugs.python.org/issue1875> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36229] Avoid unnecessary copies for list, set, and bytearray ops.

Armin Rigo added the comment: ...or PySequence_Concat() instead of PyNumber_Add(); same reasoning. -- ___ Python tracker <https://bugs.python.org/issue36

[issue36229] Avoid unnecessary copies for list, set, and bytearray ops.

Armin Rigo added the comment: This patch is based on the following reasoning: if 'a' is a list and the reference count of 'a' is equal to 1, then we can mutate in-place 'a' in a call to 'a->ob_type->tp_as_sequence->list_concat'. Typically that is called from 'PyNumber

[issue36124] Provide convenient C API for storing per-interpreter state

Armin Rigo added the comment: PyModule_GetState() requires having the module object that corresponds to the given interpreter state. I'm not sure how a C extension module is supposed to get its own module object corresponding to the current interpreter state, without getting it from

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

Armin Rigo added the comment: Done. -- ___ Python tracker <https://bugs.python.org/issue35886> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

Armin Rigo added the comment: Cool. Also, no bugfix release of cffi was planned, but I can make one if you think it might help for testing the current pre-release of CPython 3.8. -- ___ Python tracker <https://bugs.python.org/issue35

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

Armin Rigo added the comment: @nick the C sources produced by cffi don't change. When they are compiled, they use Py_LIMITED_API so you can continue using a single compiled module version for any recent-enough Python 3.x. The required fix is only inside the cffi module itself

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

Armin Rigo added the comment: Just so you know, when we look at the changes to CPython, the easiest fix is to add these lines in cffi: #if PY_VERSION_HEX >= 0x0308 # define Py_BUILD_CORE # include "internal/pycore_pystate.h" # undef Py_BUILD_CORE #endif

[issue34880] About the "assert" bytecode

Armin Rigo added the comment: A middle ground might be to copy the behavior of ``__import__``: it is loaded from the builtins module where specific hacks can change its definition, but it is not loaded from the globals. -- nosy: +arigo ___ Python

[issue9134] sre bug: lastmark_save/restore

Change by Armin Rigo : -- nosy: -arigo ___ Python tracker <https://bugs.python.org/issue9134> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"

Change by Armin Rigo : -- nosy: -arigo ___ Python tracker <https://bugs.python.org/issue25750> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34123] ambiguous documentation for dict.popitem

Armin Rigo added the comment: Agreed with Raymond. -- ___ Python tracker <https://bugs.python.org/issue34123> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex

Armin Rigo added the comment: cffi supports complex numbers since release 1.11---for direct calls using the API mode. That means that neither CFFI's ABI mode, nor ctypes, can possibly work yet. The problem is still libffi's own support, which is still not implemented (apart on a very

[issue1617161] Instance methods compare equal when their self's are equal

Change by Armin Rigo : -- nosy: -arigo ___ Python tracker <https://bugs.python.org/issue1617161> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1366311] SRE engine should release the GIL when/if possible

Change by Armin Rigo <ar...@users.sourceforge.net>: -- nosy: -arigo ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue1366311> ___

[issue32922] dbm.open() encodes filename with default encoding rather than the filesystem encoding

Armin Rigo <ar...@users.sourceforge.net> added the comment: It's not a new feature. See for example all functions from posixmodule.c: it should at least be PyArg_ParseTuple(args, "et", Py_FileSystemDefaultEncoding, _star_variable). ---

Re: Re: Progress migrating cffi and pycparser to libclang

a CFFI build script in order to provide content to ffi.cdef(). A bientôt, Armin. -- https://mail.python.org/mailman/listinfo/python-list

[issue21288] hashlib.pbkdf2_hmac Hash Constructor

Armin Ronacher <armin.ronac...@active-4.com> added the comment: I have no good solution. What I do so far is pretty much exactly what was originally reported here: https://github.com/pallets/werkzeug/blob/6922d883ba61c6884fa6cab5bfd280c5a60399af/werkzeug/security.py#L9

[issue21288] hashlib.pbkdf2_hmac Hash Constructor

Armin Ronacher <armin.ronac...@active-4.com> added the comment: Yes, I'm definitely still interested in this. I still carry this hack around. -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue17852] Built-in module _io can lose data from buffered files at exit

Change by Armin Rigo <ar...@users.sourceforge.net>: -- nosy: -arigo ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17852> ___ _

[issue1617161] Instance methods compare equal when their self's are equal

Armin Rigo <ar...@users.sourceforge.net> added the comment: Sorry, I think it is pointless to spend efforts to keep a relatively uncontroversial and small patch up-to-date, when it was not accepted in 9 years. Someone else would need to take

[issue10544] yield expression inside generator expression does nothing

Change by Armin Rigo <ar...@users.sourceforge.net>: -- nosy: -arigo ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ _

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

Armin Rigo <ar...@users.sourceforge.net> added the comment: Guido: you must be tired and forgot that locals() is a regular function :-) The compiler cannot recognize it reliably. Moreover, if f_locals can be modified outside a tracing hook, then we have the same problem in a cross-fu

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

Armin Rigo <ar...@users.sourceforge.net> added the comment: Thanks Nick for the clarification. Yes, that's what I meant: supporting such code in simple JITs is a nightmare. Perhaps more importantly, I am sure that if Python starts supporting random mutation of locals outside tracing

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

Armin Rigo <ar...@users.sourceforge.net> added the comment: FWIW, a Psyco-level JIT compiler can support reads from locals() or f_locals, but writes are harder. The need to support writes would likely become another hard step on the way towards adding some simple JIT support to C

[issue29943] PySlice_GetIndicesEx change broke ABI in 3.5 and 3.6 branches

Armin Rigo <ar...@users.sourceforge.net> added the comment: An update to Serhiy's proposed fix: #if PY_VERSION_HEX < 0x0307 && defined(PySlice_GetIndicesEx) #if !defined(PYPY_VERSION) #undef PySlice_GetIndicesEx #endif #endif All PyXxx functions are macros on PyPy, and u

[issue31265] Remove doubly-linked list from C OrderedDict

Armin Rigo added the comment: I would side with Inada in thinking they both give the same amortized complexity, but beyond that, benchmarks are the real answer. There is little value in keeping the current implementation of OrderedDict *if* benchmarks show that it is rarely faster

[issue31119] Signal tripped flags need memory barriers

Armin Rigo added the comment: For reference, no, it can't happen on x86 or x86-64. I've found that this simplified model actually works for reasoning about ordering at the hardware level: think about each core as a cache-less machine that always *reads* from the central RAM, but that has

[issue31105] Cyclic GC threshold may need tweaks

New submission from Armin Rigo: The cyclic GC uses a simple and somewhat naive policy to know when it must run. It is based on counting "+1" for every call to _PyObject_GC_Alloc(). Explicit calls to PyObject_GC_Del() are counted as "-1". The cyclic GC will only be exec

[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

New submission from Armin Rigo: multiprocessing.queues.SimpleQueue should have a close() method. This is needed to explicitly release the two file descriptors of the Pipe used internally. Without it, the file descriptors leak if a reference to the SimpleQueue object happens to stay around

[issue30879] os.listdir(bytes) gives a list of bytes, but os.listdir(buffer) gives a list of unicodes

Armin Rigo added the comment: I've also been pointed to https://bugs.python.org/issue26800 . -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue30879] os.listdir(bytes) gives a list of bytes, but os.listdir(buffer) gives a list of unicodes

New submission from Armin Rigo: The ``os`` functions generally accept any buffer-supporting object as file names, and interpret it as if ``bytes()`` had been called on it. However, ``os.listdir(x)`` uses the type of ``x`` to know if it should return a list of bytes or a list of unicodes

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

Armin Rigo added the comment: (Note: x.py is for Python 2.7; for 3.x, of course, replace ``.next()`` with ``.__next__()``. The result is the same) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

Armin Rigo added the comment: A version of the same problem without threads, using generators instead to get the bug deterministically. Prints 1, 1, 1, 1 on CPython and 1, 2, 3, 3 on PyPy; in both cases we would rather expect 1, 2, 3, 4. -- Added file: http://bugs.python.org

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- nosy: +arigo ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30744> ___ _

[issue30480] samefile and sameopenfile fail for WebDAV mapped drives

Armin Rigo added the comment: Another example of this misbehaviour: there are cases where ``os.stat()`` will internally fail to obtain the whole stat info (in some case related to permissions) and silently fall back to the same behaviour as Python 2.7. In particular, it will return a result

[issue29535] datetime hash is deterministic in some cases

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- pull_requests: +2016 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue24340] co_stacksize estimate can be highly off

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- versions: +Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue28647] python --help: -u is misdocumented as binary mode

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- nosy: -arigo ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28647> ___ _

[issue18943] argparse: default args in mutually exclusive groups

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- nosy: -arigo ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18943> ___ _

[issue30347] itertools.groupby() can fail a C assert()

New submission from Armin Rigo: This triggers an assert() failure on debug-mode Python (or a leak in release Python): from itertools import groupby def f(n): print("enter:", n) if n == 5: list(b) print("leave:", n) return n != 6 for (k, b) in

[issue30080] Add the --duplicate option for timeit

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- nosy: -arigo ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30080> ___ _

[issue29694] race condition in pathlib mkdir with flags parents=True

Armin Rigo added the comment: https://github.com/python/cpython/pull/1089 (I fixed the problem with my CLA check. Now https://cpython-devguide.readthedocs.io/pullrequest.html#licensing says "you can ask for the CLA check to be run again" but doesn't tell how to do that, so as fa

[issue29694] race condition in pathlib mkdir with flags parents=True

Armin Rigo added the comment: Update: a review didn't show any other similar problems (pathlib.py is a thin layer after all). Applied the fix and test (x2.diff) inside PyPy. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.p

[issue29694] race condition in pathlib mkdir with flags parents=True

Armin Rigo added the comment: Maybe we should review pathlib.py for this kind of issues and first apply the fixes and new tests inside PyPy. That sounds like a better way to get things done for these rare issues, where CPython is understandably reluctant to do much changes. Note

[issue29694] race condition in pathlib mkdir with flags parents=True

Armin Rigo added the comment: Changes including a test. The test should check all combinations of "concurrent" creation of the directory. It hacks around at pathlib._normal_accessor.mkdir (patching "os.mkdir" has no effect, as the built-in function was already extract

[issue29694] race condition in pathlib mkdir with flags parents=True

Armin Rigo added the comment: It's a mess to write a test, because the exact semantics of .mkdir() are not defined as far as I can tell. This patch is a best-effort attempt at making .mkdir() work in the presence of common parallel filesystem changes, that is, other processes that would

[issue29694] race condition in pathlib mkdir with flags parents=True

Armin Rigo added the comment: A different bug in the same code: if someone creates the directory itself between the two calls to ``self._accessor.mkdir(self, mode)``, then the function will fail with an exception even if ``exist_ok=True``. Attached is a patch that fixes both cases

[issue29602] complex() on object with __complex__ function loses sign of zero imaginary part

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 <

[issue29602] complex() on object with __complex__ function loses sign of zero imaginary part

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

[issue29602] complex() on object with __complex__ function loses sign of zero imaginary part

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

[issue29534] _decimal difference with _pydecimal

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) # with _pydecimal

[issue29535] datetime hash is deterministic in some cases

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 constant

[issue29535] datetime hash is deterministic in some cases

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

[issue29534] _decimal difference with _pydecimal

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__: Decimal('42.5

[issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex

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

[issue10544] yield expression inside generator expression does nothing

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 versions

[issue10544] yield expression inside generator expression does nothing

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

[issue11992] sys.settrace doesn't disable tracing if a local trace function returns None

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 thi

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

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

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

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

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

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's a good

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

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

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

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 'xxx'. The second case is because _PyBytes_Format() contains more special

[issue29096] unicode_concatenate() optimization is not signal-safe (not atomic)

Changes by Armin Rigo <ar...@users.sourceforge.net>: Added file: http://bugs.python.org/file46153/patch1.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue29096] unicode_concatenate() optimization is not signal-safe (not atomic)

Changes by Armin Rigo <ar...@users.sourceforge.net>: Removed file: http://bugs.python.org/file46150/patch1.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue29096] unicode_concatenate() optimization is not signal-safe (not atomic)

Changes by Armin Rigo <ar...@users.sourceforge.net>: Added file: http://bugs.python.org/file46151/patch2.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue29096] unicode_concatenate() optimization is not signal-safe (not atomic)

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

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

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

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

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 <rep...@bugs.python.org> <htt

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

Armin Rigo added the comment: (S5) gregory: actually there is also fchown/chown in the same situation. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue28883] Python 3.5.2 crashers (from PyPy)

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- type: -> crash ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28883> ___ _

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28885> ___ _

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28884> ___ _

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

Changes by Armin Rigo <ar...@users.sourceforge.net>: -- versions: +Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

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"

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

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, so someone is wrong

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

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.values

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

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 <

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

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'm not

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

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

  1   2   3   4   5   6   >