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
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 the
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue41097>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue36229>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 tr
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
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue29535>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue34880>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue1875>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
...or PySequence_Concat() instead of PyNumber_Add(); same reasoning.
--
___
Python tracker
<https://bugs.python.org/issue36
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'. Typicall
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 fro
Armin Rigo added the comment:
Done.
--
___
Python tracker
<https://bugs.python.org/issue35886>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 i
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
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
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue9134>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue25750>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo added the comment:
Agreed with Raymond.
--
___
Python tracker
<https://bugs.python.org/issue34123>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue1617161>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue1366311>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo 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,
&char_star_variable).
--
nosy: +arigo
___
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue17852>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo 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 it up.
--
___
Python tracker
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue10544>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Rigo 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-function way, e.g. if function f1
Armin Rigo 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 hooks,
then it would open the
Armin Rigo 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 CPython in the
future, should you decide
Armin Rigo 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 undefining a macro just make
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
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
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
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
Armin Rigo added the comment:
I've also been pointed to https://bugs.python.org/issue26800 .
--
___
Python tracker
<http://bugs.python.org/issue30879>
___
___
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
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
<http://bugs.python.org/issue30
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
Changes by Armin Rigo :
--
nosy: +arigo
___
Python tracker
<http://bugs.python.org/issue30744>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Armin Rigo :
--
pull_requests: +2016
___
Python tracker
<http://bugs.python.org/issue29535>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Rigo :
--
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/issue24340>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue28647>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue18943>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue30080>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
<http://bugs.python.org/is
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 that the
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
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
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
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
<
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:
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:
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)
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
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
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
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
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:
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:
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:
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:
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:
...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:
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:
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:
> 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:
(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 '
Changes by Armin Rigo :
Added file: http://bugs.python.org/file46153/patch1.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/file46151/patch2.diff
___
Python tracker
<http://bugs.python.org/issue29096>
___
___
Python-bugs-list mailin
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
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:
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
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:
(S5) gregory: actually there is also fchown/chown in the same situation.
--
___
Python tracker
<http://bugs.python.org/issue28
Changes by Armin Rigo :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue28883>
___
___
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: -> behavior
___
Python tracker
<http://bugs.python.org/issue28884>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Armin Rigo :
--
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue28885>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
(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:
(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
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:
(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:
(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:
(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:
(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:
(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:
(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_
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
1 - 100 of 384 matches
Mail list logo