Armin Rigo added the comment:
Crashes for me on Python 2.5 and 2.6, but no longer on Python 2.7. The problem
may have been fixed in the meantime.
--
___
Python tracker
<http://bugs.python.org/issue14
Armin Rigo added the comment:
I will attempt a last time to mention that the docstrings in borrowed_ref_*.py
used to say they were *examples*.
That means: (1) find any internal or external C function that returns a
borrowed reference; (2) find all callers and write down all the places that
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/issue34880>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Rigo :
--
nosy: +arigo
___
Python tracker
<http://bugs.python.org/issue30744>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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:
I've also been pointed to https://bugs.python.org/issue26800 .
--
___
Python tracker
<http://bugs.python.org/issue30879>
___
___
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
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
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
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:
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:
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:
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:
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:
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:
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
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue30080>
___
___
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/issue18943>
___
___
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 :
--
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/issue24340>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Rigo :
--
pull_requests: +2016
___
Python tracker
<http://bugs.python.org/issue29535>
___
___
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
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:
@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:
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:
Done.
--
___
Python tracker
<https://bugs.python.org/issue35886>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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:
...or PySequence_Concat() instead of PyNumber_Add(); same reasoning.
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue1875>
___
___
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
___
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:
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:
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:
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
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue10544>
___
___
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/issue17852>
___
___
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:
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue1617161>
___
___
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
Armin Rigo added the comment:
Agreed with Raymond.
--
___
Python tracker
<https://bugs.python.org/issue34123>
___
___
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:
Change by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<https://bugs.python.org/issue9134>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
New submission from Armin Rigo:
If you have in x some very large number, like 3**20, then the computation
for 'str(x)' is sub-efficient. Nathan Hurst posted to the pypy-dev mailing
list a pure Python algo that gives the same result in 2/3rd of the time (in
either CPython or
Armin Rigo added the comment:
Thanks, I missed it. Sorry for the noise.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Armin Rigo:
A new bug, introduced in recent Python 2.7 (2.7.3 passes, 2.7 trunk fails):
With the attached x.py, running "python -c 'import x'" fails with RuntimeError:
not holding the import lock.
It occurs when doing a fork() while holding the impor
Armin Rigo added the comment:
The bug is different, because it doesn't depend on details of the platform.
--
___
Python tracker
<http://bugs.python.org/is
Armin Rigo added the comment:
Indeed, no clue: it seems I don't get the error only on my system-installed
2.7.3 on Linux 32. I do get it on any other Python I tried, like 2.6.x, or the
system-installed 2.7.1 on Linux 64. So it's not actually
Armin Rigo added the comment:
That's not really what I'm after, but that's a workaround I proposed to avoid
the worst breakage. I don't have an opinion about what to do with symlinks.
--
___
Python tracker
<http://bug
Armin Rigo added the comment:
Brett: I don't really have a constructive opinion on this matter. I could
suggest putting a bit more logic in py_compile.compile(cfile=...) to revert to
the old behavior if we specify an already-existing target, in order to fix the
other reported issue
Armin Rigo added the comment:
A slightly more complete example that I tested:
http://stackoverflow.com/a/16077568/1556290
--
nosy: +arigo
___
Python tracker
<http://bugs.python.org/issue18
Armin Rigo added the comment:
Just a side note for 2.7: could I recommend people to be really extra, extra
careful when changing what kind of regexps are accepted and what kind of
regexps are outright rejected? I believe the risk of making long-existing and
working 2.7 programs suddenly
Armin Rigo added the comment:
Just mentioning it here again, but "type(a).__index__(a)" is still not
perfectly correct. Attached is a case where it differs.
I think you get always the correct answer by evaluating "range(a).stop". It's
admittedly obscure...
Armin Rigo added the comment:
> The difference doesn't look significant. In all cases the TypeError is raised.
Ok, so here is another case. (I won't go to great lengths trying to convince
you that there is a problem, because the discussion already occurred several
times; googl
Armin Rigo added the comment:
This may have been the most recent discussion of this idea (as far as I can
tell):
http://mail.python.org/pipermail//python-ideas/2012-August/016036.html
Basically, it seems to be still unresolved in the trunk Python; sorry, I
thought by now it would have been
Armin Rigo added the comment:
Sorry, realized that my pure Python algorithm isn't equivalent to
_PyType_Lookup() --- it fails the staticmethod example of Serhiy. A closer one
would be:
for t in type(a).__mro__:
if '__index__' in t.__dict__:
re
Armin Rigo added the comment:
For completeness, can you post one line saying why the much simpler solution
"range(a).stop" is not accepted?
--
___
Python tracker
<http://bugs.python.o
Armin Rigo added the comment:
Ah. If that's the only reason, then that seems a bit like misguided effort...
For alternative implementations like PyPy and Jython, the "_operator" module is
definitely one of the simplest ones to reimplement in RPython or Java. Eve
Armin Rigo added the comment:
...but yes, it's very obvious that exposing _PyType_Lookup() to pure Python is
the right thing to do here. This is a central part of the way Python works
internally, after all.
Moreover, sorry about my previous note: if we started today to write PyPy, the
Armin Rigo added the comment:
@Serhiy: it would certainly break a program that tries to call the repr() and
catches the UnicodeEncodeError to do something else, like encode the data
differently.
--
___
Python tracker
<http://bugs.python.
Armin Rigo added the comment:
@Serhiy: it's a behavior change and as such not an option for a micro release.
For example, the following legal code would behave differently: it would
compute s = '\\u1234' instead of s = 'UTF8:\xe1\x88\xb4'.
try:
Changes by Armin Rigo :
--
nosy: +arigo
___
Python tracker
<http://bugs.python.org/issue18885>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
New submission from Armin Rigo:
In argparse, default arguments have a strange behavior that shows up in
mutually exclusive groups: specifying explicitly on the command-line an
argument, but giving it its default value, is sometimes equivalent to not
specifying the argument at all, and
Changes by Armin Rigo :
--
keywords: -patch
___
Python tracker
<http://bugs.python.org/issue18943>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Rigo :
--
components: +Library (Lib)
___
Python tracker
<http://bugs.python.org/issue18943>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Armin Rigo:
Found a minor mistake in test_set.py. Patch attached.
--
components: Interpreter Core
files: test_set.diff
keywords: patch
messages: 197060
nosy: arigo
priority: normal
severity: normal
status: open
title: Minor mistake in test_set.py
versions: Python
Armin Rigo added the comment:
I believe that this describes a problem more general than the problem of Enums
from Issue18693: help(x) shouldn't crash in the presence of a __dir__() method
that returns unexpected names.
--
nosy: +arigo
___
P
Changes by Armin Rigo :
--
assignee: -> tim.peters
___
Python tracker
<http://bugs.python.org/issue18944>
___
___
Python-bugs-list mailing list
Unsubscrib
Armin Rigo added the comment:
The __objclass__ is a workaround. I don't understand your point. I think the
original poster is saying that simply putting a __dir__() method on a class can
confuse help() more than would be necessary, and if he's correct I agree
Armin Rigo added the comment:
Getting consistently one behavior or the other would be much better imho; I
think it's wrong-ish to have the behavior depend uncontrollably on
implementation details. But I agree that it's slightly messy to declare which
of the two possible fixes is
Armin Rigo added the comment:
Fwiw I agree with you :-) I'm just relaying a bug report that originates on
PyPy (https://bugs.pypy.org/issue1595).
--
___
Python tracker
<http://bugs.python.org/is
Armin Rigo added the comment:
The patch looks good to me. It may break existing code, though, as reported on
https://bugs.pypy.org/issue1595. I would say that it should only go to trunk.
We can always fix PyPy (at Python 2.7) in a custom manner, in a "bug-to-bug"
compatib
Armin Rigo added the comment:
Sorry to re-open this issue. The following example shows that it was not fully
resolved:
def f():
return u'\U00023456abcdef'[3]
import dis; dis.dis(f)
print f()
On a wide build it should print 'c' and on a narrow buil
Armin Rigo added the comment:
Unlike other crashers I'm a bit concerned about this one. It can occur on any
code that stores custom instances as keys in the __dict__ of an old-style
instance. Such code might be unusual-looking, but certainly not unheard-of.
And the segfault that w
Armin Rigo added the comment:
Did anyone ever show that this particular detail, which looks like a completely
obscure case to me, has any measurable effect on any code whatsoever? Just
coming up with numbers, but I'm sure it gives you 5% on the most specially
tuned micro-benchmark
Armin Rigo added the comment:
fijal: while I agree with you, the limit for small ints has actually been
pushed to 257 in recent CPythons. So it should still theoretically work --- of
course, assuming a predictable CPU, which is wrong, and assuming a simple
interpreter. (We can probably dig
Changes by Armin Rigo :
--
nosy: -arigo
___
Python tracker
<http://bugs.python.org/issue15061>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Armin Rigo:
A small bug of cvs.reader():
>>> list(csv.reader(['foo:"'], delimiter=':', quotechar='"'))
[]
Adding strict=True doesn't change anything. This is caused by the opening
quote not followed by anything, which
Armin Rigo added the comment:
Just to make it extra clear: Vlado showed that the "-R" switch of Python can
easily be made fully pointless, with only a bit of extra work. Here is how:
* Assume you have an algo that gives you as many strings with colliding hashes
as you want, provide
Armin Rigo added the comment:
For reference, the above means that we can implement -R support for PyPy as a
dummy ignored flag, and get "security" that is very close to CPython's. :-)
--
keywords: +easy
___
Python tracker
<http
New submission from Armin Rigo:
On Posix, it is documented that setting PATH to the empty string is equivalent
to not setting PATH at all, which is an exception to the rule that in a string
like "/bin::/usr/bin" the empty string in the middle gets interpreted as ".".
PYTH
Armin Rigo added the comment:
Attached the diff, in case we want to do that. The diff is only about
non-Windows platforms, given that it follows a Posix use case about PATH. But
do we also need to change PC/getpathp.c?
--
keywords: +patch
Added file: http://bugs.python.org/file27709
Armin Rigo added the comment:
Attached another simpler diff (only one "+" line instead of two...).
--
Added file: http://bugs.python.org/file27712/pythonpath2.diff
___
Python tracker
<http://bugs.python.o
New submission from Armin Rigo:
The implementation of dict.fromkeys() assumes that the new dictionary is empty.
That's not the case if we tweak __new__. Attached example shows
'dictresize(mp, 0)' being called with 'mp' being dictionary of 10 items. This
causes an
Armin Rigo added the comment:
In case of doubt, see the source code of PyPy :-)
w_dict = space.call_function(w_type)
for w_key in space.listview(w_keys):
space.setitem(w_dict, w_key, w_fill)
(Seriously more compact.) No clear there
Armin Rigo added the comment:
Joke apart, you could check and complain if the object returned is an instance
of 'dict' and is not empty. Otherwise just accept it. I think complaining is
better than picking either of the two behaviors in
New submission from Armin Rigo:
The docs still say that the default __hash__() is equal to id(), but that's not
the case since Python 2.7.
--
assignee: docs@python
components: Documentation
files: lang-ref-fix.diff
keywords: patch
messages: 215517
nosy: arigo, docs@python
pri
Armin Rigo added the comment:
Terry: I meant exactly what I wrote, and not some unrelated examples:
def f():
n = 1
class A: n = n
doesn't work, but the same two lines ("n = 1"; "class A: n = n") work if
written at module level
New submission from Armin Rigo:
Following the documentation at https://docs.python.org/3/c-api/buffer.html, if
we write a custom object in C with a getbufferproc that simply returns
PyBuffer_FillInfo(...), then it works fine up to Python 3.2 but segfaults in
Python 3.3 depending on what we do
Changes by Armin Rigo :
Added file: http://bugs.python.org/file35655/xymodule.c
___
Python tracker
<http://bugs.python.org/issue21778>
___
___
Python-bugs-list mailin
Armin Rigo added the comment:
Ah! Thanks. I systematically missed the "flags" arguments passed in the
getbufferproc function.
(I thought I had to tell PyBuffer_FillInfo() what kind of format we actually
provide, but it seems that the interface is the other way around. I don&#x
Changes by Armin Rigo :
--
resolution: -> not a bug
___
Python tracker
<http://bugs.python.org/issue21778>
___
___
Python-bugs-list mailing list
Unsubscrib
Armin Rigo added the comment:
Benjamin: oups, sorry. I don't remember setting the "easy" keyword, my mistake.
Fwiw I'm +1 on Marc-Andre's solution. Make it a tunable setting, e.g. with
sys.setcollisionlimit(). Defaults to sys.maxint on existing Pythons and some
s
Armin Rigo added the comment:
Marc-André: estimating the risks of giving up on a valid query for a truly
random hash, at an overestimated one billion queries per second, in a 2/3 full
dictionary:
* for 1000: 4E159 years between mistakes
* for 100: 12.9 years between mistakes
* for 150: 8E9
101 - 200 of 384 matches
Mail list logo
