Jeroen Demeyer added the comment:
> I want to leave low-order hash bits alone. That's deliberate.
Since I didn't understand the rationale for this and since shifting << 1 also
seems to work well, I edited PR 9471 to use DJBX33A with t ^= t << 1.
Since you insisted
Jeroen Demeyer added the comment:
> j is even implies (j ^ -3) == -(j ^ 3)
This follows from what I posted before: if j is even, then j ^ 3 is odd, so we
can apply the rule x ^ -2 = -x to x = j ^ 3:
(j ^ 3) ^ -2 = -(j ^ 3)
which implies
j ^ (3 ^ -2) = -(j ^ 3)
or equivalently
j ^
Jeroen Demeyer added the comment:
> And one more:
x = (x * mult) ^ t;
also appears to work equally well.
The order of operations does not really matter: you can write the loop as
x *= mult # Appears only in FNV-1
x ^= t[0]
x *= mult
x ^= t[1]
x *= mult
x ^= t[2]
x *= mult
x ^
Jeroen Demeyer added the comment:
> The low bits are already un-improvable in the most important cases.
Maybe you misunderstood me. Suppose that there is a hash collision, say
hash((3, 3)) == hash((-3, -3)) and you change the hashing algorithm to fix this
collision. If that change d
Jeroen Demeyer added the comment:
> It would be good if PyType_Ready() will check that base class of static type
> is static.
What's the rationale for this change? It's not explained in this bug report nor
in the code.
--
nosy: +jd
Jeroen Demeyer added the comment:
> There are _two_ hash functions at play in that collision: the tuple hash
> function, and the integer hash function. Regardless of whether the _tuple_
> hash function does [anything involving just `t`], that only directly affects
>
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Jeroen Demeyer :
It's not hard to come up with a hash collision for tuples:
>>> hash( (1,0,0) )
2528505496374819208
>>> hash( (1,-2,-2) )
2528505496374819208
The underlying reason is that the hashing code mixes ^ and *. This can create
collisions beca
Jeroen Demeyer added the comment:
> Nor is it hard to come up with collisions for most simple hash functions.
The Bernstein hash algorithm is a simple algorithm for which it can be proven
mathematically that collisions cannot be generated if the multiplier is
unknown. That is an object
Jeroen Demeyer added the comment:
> We shouldn't feel shoved into altering something that we don't agree is broken
It *is* broken. You are just denying the reality.
That's also the reason that I'm insisting so much: I don't want to push my
personal fix (despite that it may seem so), I w
Jeroen Demeyer added the comment:
Thanks for the reference, I never heard of the FNV hash. Unfortunately, I
haven't seen a reference for the rationale of how they pick their multiplier.
It's not clear what you are suggesting though. Keep using the FNV-ish hash
somehow? Or using a DJBX33A
Jeroen Demeyer added the comment:
> the made-up hacks Python used to worm around a class of gross flaws its prior
> DJBX33X approach suffered, taking DJBX33X out of its original context and
> applying it in an area it wasn't designed for.
But we know why the DJBX33A hash didn't wor
Jeroen Demeyer added the comment:
Regarding t ^= t << 7: I tested PR 9471 with all shift values from 1 to 20. The
new testsuite passed for all shifts from 1 to 13, except for 6. It failed for 6
and for 14 to 20. This indicates that smaller shift values are better (even
when looking
Jeroen Demeyer added the comment:
I spent about 2 days doing an extensive study of the FNV and DJB algorithms. I
share my conclusions below.
To be very clear what I mean, I am talking about the following algorithms (t is
a tuple and m is the multiplier which is always assumed to be odd
Jeroen Demeyer added the comment:
> In Jeroen's API, I can see what the Python-level signal handler is, but
> there's no way to find out whether that signal handler is actually in use or
> not.
I added support for that in the latest cysignals release. Now you can do
>>
Jeroen Demeyer added the comment:
For reference, the sources for my implementation:
https://github.com/sagemath/cysignals/blob/master/src/cysignals/pysignals.pyx
--
___
Python tracker
<https://bugs.python.org/issue13
Jeroen Demeyer added the comment:
I guess I should wait until PR 11507 is merged, to avoid merge conflicts.
--
___
Python tracker
<https://bugs.python.org/issue35
Jeroen Demeyer added the comment:
My proposal vastly improves the situation for Decimal. I will write a PR for
this and I hope that it won't be rejected just because it's not perfect.
--
___
Python tracker
<https://bugs.python.org/issue35
Jeroen Demeyer added the comment:
It's a relatively old Gentoo GNU/Linux system:
Linux tamiyo 3.17.7-gentoo #2 SMP PREEMPT Fri Dec 23 18:13:49 CET 2016 x86_64
Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz GenuineIntel GNU/Linux
The problem occurs when there are directories on $PATH which
Jeroen Demeyer added the comment:
To avoid code duplication, it's tempting to merge _PyTime_FromObject and
_PyTime_ObjectToDenominator
These two functions almost do the same, but not quite.
--
___
Python tracker
<https://bugs.python.
Jeroen Demeyer added the comment:
In other words: if we can only use __float__ and __int__, how do we know which
one to use?
--
___
Python tracker
<https://bugs.python.org/issue35
New submission from Jeroen Demeyer :
This test was recently added (PR 6332):
def test_no_such_executable(self):
no_such_executable = 'no_such_executable'
try:
pid = posix.posix_spawn(no_such_executable,
[no_such_executable
Jeroen Demeyer added the comment:
> If we want to support other numerical types with loss in double rounding
Looking at the existing code, I can already see several double-rounding "bugs"
in the code, so I wouldn't be too much c
Jeroen Demeyer added the comment:
The motivation for PEP 357 was certainly using an object as the index for a
sequence, but that's not the only use case.
In fact PEP 357 states "For example, the slot can be used any time Python
requires an integer internally"
So despite the name
Jeroen Demeyer added the comment:
If __index__ doesn't "feel" right, what do you propose then to fix this issue,
keeping in mind the concerns of https://bugs.python.org/issue35707#msg333401
--
___
Python tracker
<https://bu
Change by Jeroen Demeyer :
--
pull_requests: +11407
___
Python tracker
<https://bugs.python.org/issue35707>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
There is again some discussion about this at
https://discuss.python.org/t/why-are-some-expressions-syntax-errors/420
--
___
Python tracker
<https://bugs.python.org/issue19
Change by Jeroen Demeyer :
--
pull_requests: +11407, 11408
___
Python tracker
<https://bugs.python.org/issue35707>
___
___
Python-bugs-list mailing list
Unsub
Change by Jeroen Demeyer :
--
pull_requests: +11407, 11408, 11409
___
Python tracker
<https://bugs.python.org/issue35707>
___
___
Python-bugs-list mailin
Jeroen Demeyer added the comment:
> Test with os.posix_spawn() is fine:
Indeed, the difference between posix_spawn() and posix_spawnp() is that only
the latter uses $PATH to look up the executable.
--
___
Python tracker
<https://bugs.pyth
New submission from Jeroen Demeyer :
This used to work correctly in Python 2:
class Half(object):
def __float__(self):
return 0.5
import time
time.sleep(Half())
With Python 3.6, one gets instead
Traceback (most recent call last):
File "test.py", line 6, in
time.
Jeroen Demeyer added the comment:
> I'm not sure in which order the conversion should be tried to avoid/reduce
> precision loss during the conversion.
I would suggest the order
1. __index__ to ensure exact conversion of exact integers
2. __float__ to ensure correct conversion of fl
Jeroen Demeyer added the comment:
> The correct code works for float and int (and maybe decimal.Decimal, I don't
> recall!)
Not for Decimal! In fact sleep(Decimal("0.99")) is interpreted as sleep(0)
because __int__ is
Jeroen Demeyer added the comment:
> the most reliable way is to represent them as fractions (x.as_integer_ratio()
> or (x.numerator, x.denominator))
I don't think that we can rely on non-dunder names like that. They are not
reserved names, so classes can give them any sem
Jeroen Demeyer added the comment:
> I'm also mildly concerned by how duplicative the code becomes post-patch.
I know, that's why I added that comment on GitHub.
> perhaps just implement _PyTime_ObjectToTime_t as a wrapper for
> _PyTime_ObjectToDenominator
Sure, but will that
Jeroen Demeyer added the comment:
Is anybody willing to review PR 11636?
--
___
Python tracker
<https://bugs.python.org/issue35707>
___
___
Python-bugs-list m
Jeroen Demeyer added the comment:
I created an additional PR 12607 with some more changes to the, in particular
to make the old backwards-compatibility trashcan macros safer. This should be
seen as part of the same bugfix but I decided to make a new PR because PR 11841
had several positive
Jeroen Demeyer added the comment:
> I'd propose adding "%0D%0A%0D%0AIf you are developing on another platform,
> try make regen-all and commit the updated files"
I updated the PR with wording similar to that. I don't want to bikeshed too
much about the precise wording.
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12527
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36448>
___
___
Py
Jeroen Demeyer added the comment:
I am curious, how did you find out about this bug? Do you have a concrete use
case for directly calling an instance of classmethod_descriptor? Typically, one
would write dict.fromkeys(...) instead of dict.__dict__['fromkeys'](dict, ...).
--
nosy
New submission from Jeroen Demeyer :
On Windows builds, one may get the message
C:\projects\cpython\PCbuild\_freeze_importlib.vcxproj(130,5): error :
importlib.h, importlib_external.h, importlib_zipimport.h updated. You will need
to rebuild pythoncore to see the changes.
See for example
Jeroen Demeyer added the comment:
Yes of course. When not using the trashcan, stuff crashes. I don't get your
point...
--
___
Python tracker
<https://bugs.python.org/issue35
Jeroen Demeyer added the comment:
To clarify: the purpose of MyList is specifically to check that no double
deallocations occur. For this test to make sense, MyList should not use the
trashcan itself.
--
___
Python tracker
<ht
Jeroen Demeyer added the comment:
See also PEP 590, which has very similar ideas. Also PEP 580 is related to this.
--
___
Python tracker
<https://bugs.python.org/issue29
New submission from Jeroen Demeyer :
The "instance method" class is not used anywhere and there are no obvious use
cases. We should just deprecate it to simplify Python.
See discussion at
https://mail.python.org/pipermail/python-dev/2019-April/156975.html
--
messages: 3
Change by Jeroen Demeyer :
--
title: Deprecate instance method -> Deprecate instancemethod
___
Python tracker
<https://bugs.python.org/issue36525>
___
___
Py
Change by Jeroen Demeyer :
--
pull_requests: +12612
___
Python tracker
<https://bugs.python.org/issue36347>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
> I'm tempted to call YAGNI on this.
Indeed. See https://bugs.python.org/issue36525
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/iss
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12613
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36525>
___
___
Py
Jeroen Demeyer added the comment:
> Amusingly, this is because of an old hack to make directly calling
> somedict.__getitem__ fast:
> https://github.com/python/cpython/commit/8f5cdaa784f555149adf5e94fd2e989f99d6b1db
But what's the use case of making somedict.__getitem__(x) fast? O
Jeroen Demeyer added the comment:
OK, makes sense. Also super() calls I guess: you can write
super().__getitem__(x) but not super()[x] (although the latter *could* be
implemented if we wanted to).
I see two ways of fixing this:
1. Make wrapper descriptors faster, removing the need
Jeroen Demeyer added the comment:
This should be closed.
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue29209>
___
___
Python-bugs-list m
Jeroen Demeyer added the comment:
This might be solvable using PEP 580 by using METH_VARARGS instead of
METH_FASTCALL for such functions. This would still require a temporary tuple
for the positional args but no additional dict would need to be allocated.
--
nosy: +jdemeyer
Change by Jeroen Demeyer :
--
pull_requests: +12624
___
Python tracker
<https://bugs.python.org/issue35983>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
I realized that there is a nasty interaction between the trashcan and __del__:
if you're very close to the trashcan limit and you're calling __del__, then
objects that should have been deallocated in __del__ (in particular, an object
involving self) might
Jeroen Demeyer added the comment:
Changing types like that looks like an ugly hack and a recipe for breakage. For
example, in list_dealloc(), the following needs the type to be correct:
if (numfree < PyList_MAXFREELIST && PyList_CheckExact(op))
free_list[numfree++] = o
Jeroen Demeyer added the comment:
> It disables the trashcan mechanism
Yes, it disables the trashcan in some cases. But only when using the trashcan
mechanism would probably crash CPython anyway due to a double deallocation. So
at the very least, PR 11841 improves things from "
Change by Jeroen Demeyer :
--
pull_requests: +12546
___
Python tracker
<https://bugs.python.org/issue35983>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
> As an aside, I thought we had a merge hook to check this on Travis?
For some reason, the Travis CI build on
https://github.com/python/cpython/pull/12582 isn't actually starting. It says
"Waiting for status to be reported" but I pushed
Jeroen Demeyer added the comment:
In Python 3, the resurrection issue probably appears too. But it's not so much
a problem since __del__ (mapped to tp_finalize) is only called once anyway. So
there are no bad consequences if the object is resurrected incorrectly
New submission from Jeroen Demeyer :
NOTE: because of PEP 442, this issue is specific to Python 2. This bug was
discovered while adding testcases for bpo-35983 to the Python 2.7 backport.
There is a nasty interaction between the trashcan and __del__: if you're very
close to the trashcan
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12648
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36556>
___
___
Py
Change by Jeroen Demeyer :
--
pull_requests: +12653
___
Python tracker
<https://bugs.python.org/issue35983>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
The consensus is clearly to return NotImplemented in this case, also because
that's what most builtins do, like the object() example that you mentioned.
However, I would rather keep that note and change it to say return
NotImplemented. It's an important
Jeroen Demeyer added the comment:
> I tried using compiler.compiler.remove('-Wstrict-prototypes') to no avail.
The -Wstrict-prototypes issue is a separate bug. It is fixed in Python >= 3.6
and there is an open backport PR for 2.7:
https://github.com/python/cpython/pul
Jeroen Demeyer added the comment:
See also PEP 579 (issue 11) and the thread
https://mail.python.org/pipermail/python-ideas/2018-June/051572.html
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue20
New submission from Jeroen Demeyer :
When designing an extension type subclassing an existing type, it makes sense
to call the tp_dealloc of the base class from the tp_dealloc of the subclass.
Now suppose that I'm subclassing "list" which uses the trashcan mechanism. Then
it
Jeroen Demeyer added the comment:
The problem is easily reproduced with Cython:
cdef class List(list):
cdef int deallocated
def __dealloc__(self):
if self.deallocated:
print("Deallocated twice!")
self.deallocated = 1
L = None
for i i
Jeroen Demeyer added the comment:
NOTE: also OrderedDict currently uses trashcan hacking to work around this
problem:
/* Call the base tp_dealloc(). Since it too uses the trashcan mechanism,
* temporarily decrement trash_delete_nesting to prevent triggering it
* and putting
Jeroen Demeyer added the comment:
See also https://bugs.python.org/issue35983 for another trashcan-related issue.
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue17
Jeroen Demeyer added the comment:
> Jeroen, could you share your example? I am learning the C-API of Python and
> this example could be interesting.
Either use the Cython code I posted above or run the testcase I added in PR
11841.
--
___
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +11871
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Jeroen Demeyer :
--
components: +Interpreter Core
___
Python tracker
<https://bugs.python.org/issue35707>
___
___
Python-bugs-list mailing list
Unsub
Jeroen Demeyer added the comment:
> Could you still give it a quick check?
I did just that. For reference, these are the steps:
- Checkout the "2.7" branch of the cpython git repo
- ./configure --prefix=/tmp/prefix --exec-prefix=/tmp/eprefix && make && make
Jeroen Demeyer added the comment:
(note typo in the above: /tmp/prefix/pip should be /tmp/prefix/bin/pip)
--
___
Python tracker
<https://bugs.python.org/issue25
Jeroen Demeyer added the comment:
> Fixing this on 2.7 would require additional investigation (distutils might
> have diverged)
Let's be honest, we are talking about distutils here. So it's way more likely
that it didn't diverge and that the behavior is exactly the same on 2.7 and
3
Jeroen Demeyer added the comment:
> You've got a reference leak in your __index__ based paths.
Thanks for pointing that out. I fixed that now.
--
___
Python tracker
<https://bugs.python.org/issu
Jeroen Demeyer added the comment:
> it seems that Jeroen's analysis is right.
So would you be willing to merge the PR then?
--
___
Python tracker
<https://bugs.python.org/issu
Jeroen Demeyer added the comment:
I'm not sure with what you disagree. At least, you have to admit that using
sig_atomic_t is buggy for different reasons than signal safety, namely that
there is no guarantee that one can safely convert back and forth to an &quo
Jeroen Demeyer added the comment:
> unpack the int into an array of sig_atomic_t.
What do you mean with this? You can't write a complete array atomically, so I
don't see how this would help.
--
___
Python tracker
<https://bugs.pyth
Jeroen Demeyer added the comment:
> Back in 2007 the only POSIX-compliant type allowed for that was sig_atomic_t,
> anything else was undefined.
Fair enough, but having a non-atomic type is still much better than a
completely wrong type. In other words, the requirement of fitting
Jeroen Demeyer added the comment:
> Unpacking the int would mean having one sig_atomic_t for 'invalid', using
> that instead of INVALID_FD, plus an array of sig_atomic_t for the fd itself.
> Every time you want to change the fd you first set the 'invalid' flag, then
> the indi
Jeroen Demeyer added the comment:
Also note that the documentation of the signal module already has the correct
wording:
Python signal handlers are always executed in the main Python thread, even if
the signal was received in another thread
Jeroen Demeyer added the comment:
> signalmodule.c has a hack to limit it to the main thread.
The Python signal handler always runs in the main thread, but the signal can be
caught by any thread. In other words, trip_signal() can be run by any thr
New submission from Jeroen Demeyer :
Because of some discussion that is happening on #1583 I noticed this bit of
code in the OS-level signal handler (set by the C function sigaction() or
signal()):
static void
signal_handler(int sig_num)
{
/* See NOTES section above */
if (getpid
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12711
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36601>
___
___
Py
New submission from Jeroen Demeyer :
On Linux with an old kernel:
0:03:59 load avg: 5.97 [300/420/1] test_posix failed -- running: test_tools (1
min 11 sec), test_concurrent_futures (2 min 42 sec)
test test_posix failed -- Traceback (most recent call last):
File "/usr/local/src/sage-c
Jeroen Demeyer added the comment:
> signal-safe is different from thread-safe
I know, but I think that other threads can receive signals too. So in that
case, it needs to be signal-safe as well as thread-safe.
--
___
Python tracker
<
Change by Jeroen Demeyer :
--
type: -> performance
___
Python tracker
<https://bugs.python.org/issue36616>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Jeroen Demeyer :
The bytecode interpreter uses an inline function call_function() to handle most
function calls. To check for profiling, call_function() needs to call to
PyThreadState_GET().
In the reference implementation of PEP 590, I saw that we can remove
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12764
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36616>
___
___
Py
Jeroen Demeyer added the comment:
The gain is small, but it's there.
I made some further changes:
- replacing code of the form
sp = stack_pointer;
call_function(..., , ...)
stack_pointer = sp;
by
call_function(..., _pointer, ...)
- fold the inline function do_call_core
Jeroen Demeyer added the comment:
Mark, Petr, do you agree? I like the way how the reference implementation of
PEP 590 improves the handling of profiling. However, that change really has
little to do with PEP 590, it's something that we can do independently
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13254
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36926>
___
___
Py
New submission from Jeroen Demeyer :
Once PEP 590 is implemented, it makes sense to focus on using the new
"vectorcall" calling convention, which is essentially what is currently
FastCallKeywords. To simplify things, it would also be good to use FastCallDict
in as few places a
Change by Jeroen Demeyer :
--
pull_requests: +13292
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeroen Demeyer :
Now that PEP 590 has been implemented, a lot of old code can be cleaned up. In
particular:
- get rid of _PyMethodDef_RawFastCallXXX() functions and replace them by
vectorcall functions for each calling convention
- get rid of FastCallDict
Jeroen Demeyer added the comment:
I opened a more general issue #37151
--
___
Python tracker
<https://bugs.python.org/issue36924>
___
___
Python-bugs-list mailin
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13694
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13340
___
Python tracker
<https://bugs.python.org/issu
201 - 300 of 586 matches
Mail list logo
