[issue32773] distutils should NOT preserve timestamps

Jeroen Demeyer added the comment: > if so wouldn't that still require an internal option? No, you just need to change the calls to the copy_file() function to add the keyword argument preserve_times=False If you agree, then I could easily provide

[issue32797] Tracebacks from Cython modules no longer work

New submission from Jeroen Demeyer : Displaying the source code in tracebacks for Cython-compiled extension modules in IPython no longer works due to PEP 302. Various fixes are possible, the two most obvious ones are: 1. linecache should continue searching for the source file even if

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > Why? What would that help with? PEP 302 says get_source() can return None > [if] no sources are found. Returning None implies that it's absolutely impossible that there are sources to be found. But in certain cases (in the case of Cython)

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > I don't think there's a bug in Python here, and that this is a problem that > needs to be solved on the Cython end. I'm not necessarily disagreeing here. It all depends on how ExtensionFileLoader is meant to be used. Should it try

[issue11566] hypot define in pyconfig.h clashes with g++'s cmath

Change by Jeroen Demeyer : -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue11566> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30071] Duck-typing inspect.isfunction()

Jeroen Demeyer added the comment: See https://mail.python.org/pipermail/python-ideas/2018-March/049398.html -- ___ Python tracker <https://bugs.python.org/issue30

[issue30071] Duck-typing inspect.isfunction()

Jeroen Demeyer added the comment: Superseded by https://www.python.org/dev/peps/pep-0575/ -- stage: test needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue33222] Various test failures if PYTHONUSERBASE is not canonicalized

New submission from Jeroen Demeyer : Setting PYTHONUSERBASE=/tmp/x/.. causes the Python test suite to fail: == FAIL: test_user_similar (test.test_sysconfig.TestSysConfig

[issue33261] inspect.isgeneratorfunction fails on hand-created methods

New submission from Jeroen Demeyer : The inspect functions isgeneratorfunction, iscoroutinefunction, isasyncgenfunction can fail on methods that do not have a __code__ attribute: >>> from types import MethodType >>> class Callable: ... def __call__(self, *args): ...

[issue33261] inspect.isgeneratorfunction fails on hand-created methods

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +6144 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33261> ___ ___ Py

[issue13585] Add contextlib.ExitStack

Jeroen Demeyer added the comment: Why this? _exit_wrapper.__self__ = cm It seems that you are trying to create something which is exactly like a method except that it's not a method. Is there any reason to not use an actual method? It would actually simplify the code. I ask be

[issue33265] contextlib.ExitStack abuses __self__

New submission from Jeroen Demeyer : In contextlib, there is code which roughly looks like def _exit_wrapper(exc_type, exc, tb): return cm_exit(cm, exc_type, exc, tb) _exit_wrapper.__self__ = cm This creates a new function _exit_wrapper from a given function cm_exit

[issue13585] Add contextlib.ExitStack

Jeroen Demeyer added the comment: Follow-up: https://bugs.python.org/issue33265 -- ___ Python tracker <https://bugs.python.org/issue13585> ___ ___ Python-bug

[issue33265] contextlib.ExitStack abuses __self__

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +6151 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33265> ___ ___ Py

[issue33261] inspect.isgeneratorfunction fails on hand-created methods

Jeroen Demeyer added the comment: > I am wondering if, instead, the bug is in m, the object returned by > MethodType, or in attribute lookup thereupon. What would you expect m.__code__ to return then? Methods support arbitrary callables and certainly not all callables have a mean

[issue33261] inspect.isgeneratorfunction fails on hand-created methods

Jeroen Demeyer added the comment: The only attributes that a method is guaranteed to have are __func__ and __self__ (which are the arguments passed to the MethodType constructor). All other attributes are looked up through __func__ by the C version of the following Python code: def

[issue33261] inspect.isgeneratorfunction fails on hand-created methods

Jeroen Demeyer added the comment: > I would like python_coded_callable.__code__ to be the code object executed > when python_coded_callable is called First of all, that doesn't answer the question of what to do with non-Python coded callables where there is no __code__ object at a

[issue33261] inspect.isgeneratorfunction fails on hand-created methods

Jeroen Demeyer added the comment: Can we please go back to the original issue? If you think that __code__ should be an alias for __call__.__code__, that is a different issue. On https://github.com/python/cpython/pull/6448#issuecomment-381507329 I posted an alternative solution for the

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: Alternatively, instead of not implementing `loader.get_source()`, we could define a new semantic: if it returns `NotImplemented`, assume that the loader doesn't know how to get the sources. In that case, linecache would fall back to the old beha

[issue32797] Tracebacks from Cython modules no longer work

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +6349 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32797> ___ ___ Py

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > IMO, debating whether a None return means there's absolutely no chance of > there being source is silly - the best the loader can say is that it can't > provide source. I don't think it is silly: if "None" means that the

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: Since you are asking various "meta" questions, let me explain the wider context first. This bug report is coming from SageMath. Currently, SageMath only supports Python 2.7 but we are slowly and steadily porting it to Python 3. This bug is one o

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > But the standard library has no need to ever find source for extension modules > So there's no need for the stdlib to be involved The standard library is not a closed system. It's not meant to support only itself, it's supp

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > How does CPython display the source for tracebacks in Cython modules? Do you mean the "python" command-line program? That uses a different algorithm: to find a file FOO, it searches [os.path.join(p, os.path.basename(FOO)) for p in sys.p

[issue33418] Memory leaks in functions

New submission from Jeroen Demeyer : This is a memory leak: >>> while True: ...def f(): pass ...f.__doc__ = f This also: >>> while True: ...

[issue33418] Memory leaks in functions

Change by Jeroen Demeyer : -- components: +Interpreter Core type: -> resource usage ___ Python tracker <https://bugs.python.org/issue33418> ___ ___ Python-

[issue33445] test_cprofile should fail instead of displaying a message

New submission from Jeroen Demeyer : When this test from Lib/test/test_profile.py fail, it just prints a message and doesn't fail the testsuite: def test_cprofile(self): results = self.do_profiling() expected = self.get_expected_output() self.assertEqual(resu

[issue33445] test_cprofile should fail instead of displaying a message

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +6420 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33445> ___ ___ Py

[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"

Change by Jeroen Demeyer : -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"

Change by Jeroen Demeyer : -- pull_requests: +6476 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue5755> ___ ___ Python-bugs-list mai

[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"

Jeroen Demeyer added the comment: > Or just remove it I updated the PR to do that. I didn't want to propose that initially because that patch was proposed here almost 2 years ago but not accepted. -- ___ Python tracker <https://bugs

[issue31388] Provide a way to defer SIGINT handling in the current thread

Jeroen Demeyer added the comment: It's not only about ensuring that cleanup code gets run, but also about ensuring that the interrupt is actually seen. Currently, if you press CTRL-C at the "wrong" moment (during __del__), it will just get ignored. --

[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"

Jeroen Demeyer added the comment: > Can we backport this to 3.7 and 3.6? I think it's safe and helpful. And 2.7 for the same reasons. -- ___ Python tracker <https://bugs.python.or

[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"

Jeroen Demeyer added the comment: > 2.7 doesn't have CFLAGS_NODIST I meant backporting this patch as-is to 2.7 without adding -Wstrict-prototypes to CFLAGS_NODIST -- ___ Python tracker <https://bugs.python.or

[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"

Change by Jeroen Demeyer : -- pull_requests: +7099 ___ Python tracker <https://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33925] builtin_function_or_method compares __self__ by identity instead of equality

New submission from Jeroen Demeyer : Methods of Python functions compare equal if the functions are equal and if __self__ is equal: >>> class X: ... def __eq__(self, other): return True ... def meth(self): pass >>> X().meth == X().meth True This is because X() ==

[issue33925] builtin_function_or_method compares __self__ by identity instead of equality

Jeroen Demeyer added the comment: > This is a duplicate of issue1617161. Well, it's really the opposite. That issue seems to be arguing that __self__ should be compared using "is" while I think it should be compared using "==". -- __

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

Jeroen Demeyer added the comment: I just posted to python-dev about this issue: https://mail.python.org/pipermail/python-dev/2018-June/153959.html However, I think that comparing using "==" is the right thing to do. So I think that >>> [].append == [].append False s

[issue33939] Raise TypeError in __length_hint__ for consistently infinite iterators

Jeroen Demeyer added the comment: Why TypeError? Wouldn't OverflowError be more suitable? -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/is

[issue33939] Raise TypeError in __length_hint__ for consistently infinite iterators

Jeroen Demeyer added the comment: I'm certainly in favor of adding a way for infinite iterators to state that they are infinite. I just feel like TypeError is way overused in Python. I also disagree that it's a category error: it's an iterable, so it does make sense to ask

[issue33939] Raise TypeError in __length_hint__ for consistently infinite iterators

Jeroen Demeyer added the comment: By the way, there is a precedent for OverflowError on infinities: >>> import math >>> int(math.inf) Traceback (most recent call last): File "", line 1, in OverflowError: cannot conve

[issue33418] Memory leaks in functions

Jeroen Demeyer added the comment: > While this is a obvious bug, f.__module__ = f seems very unnatural. Sure. -- ___ Python tracker <https://bugs.python.org/issu

[issue19660] decorator syntax: allow testlist instead of just dotted_name

Jeroen Demeyer added the comment: Real world example where this actually came up: https://github.com/jupyter-widgets/ipywidgets/issues/430#issuecomment-247016263 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue19

[issue34125] Profiling depends on whether **kwargs is given

New submission from Jeroen Demeyer : Enable profiling for C functions: >>> def prof(frame, typ, arg): ... if typ.startswith("c_"): ... print(arg, typ) >>> import sys; sys.setprofile(prof) and notice how profiling depends on **kwargs:

[issue34126] Profiling dict.get() crashes Python

New submission from Jeroen Demeyer : >>> import sys; sys.setprofile(lambda *args:None) >>> dict.get() Segmentation fault -- components: Interpreter Core messages: 321747 nosy: jdemeyer priority: normal severity: normal status: open title: Profiling dict.get() crash

[issue34126] Profiling dict.get() crashes Python

Jeroen Demeyer added the comment: Simple patch coming up... -- ___ Python tracker <https://bugs.python.org/issue34126> ___ ___ Python-bugs-list mailin

[issue34126] Profiling certain invalid calls crash Python

Jeroen Demeyer added the comment: Also: >>> import sys; sys.setprofile(lambda *args: None) >>> dict.get([], "foo") Segmentation fault -- title: Profiling dict.get() crashes Python -> Profiling cert

[issue34126] Profiling certain invalid calls crash Python

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +7834 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34126> ___ ___ Py

[issue34190] x86 Gentoo Refleaks 3.x: test_sys_setprofile leaked [1, 1, 1] references, sum=3

Jeroen Demeyer added the comment: Just to avoid duplicate work: I can have a look at this. -- ___ Python tracker <https://bugs.python.org/issue34190> ___ ___

[issue34190] x86 Gentoo Refleaks 3.x: test_sys_setprofile leaked [1, 1, 1] references, sum=3

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +7939 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34190> ___ ___ Py

[issue34125] Profiling depends on whether **kwargs is given

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +7942 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34125> ___ ___ Py

[issue34245] Python library should be installed writable

New submission from Jeroen Demeyer : In Makefile.pre.in, there is this: # Shared libraries must be installed with executable mode on some systems; # rather than figuring out exactly which, we always give them executable mode. # Also, making them read-only seems to be a good idea

[issue34245] Python library should be installed writable

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +8012 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34245> ___ ___ Py

[issue34245] Python library should be installed writable

Jeroen Demeyer added the comment: > Isn't it useful to avoid accidental change while open files with editor for > just reading? Why would that argument apply to a binary file (and only to binary files)? > Is there any real world problem about read-only library? It makes it s

[issue34245] Python library should be installed writable

Jeroen Demeyer added the comment: Also, some tools may want to edit the library after installation. Rebasing on Cygwin is an example of that. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34280] METH_NOARGS: no longer require that second arg is NULL

New submission from Jeroen Demeyer : A C function with signature METH_NOARGS takes two arguments where the first is "self" and the second is guaranteed to be NULL. Given that this second argument really should never be used, I would like to drop the guarantee that the argume

[issue34280] METH_NOARGS: no longer require that second arg is NULL

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +8077 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34280> ___ ___ Py

[issue34280] METH_NOARGS: no longer require that second arg is NULL

Change by Jeroen Demeyer : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34280> ___ ___ Pyth

[issue34280] METH_NOARGS: no longer require that second arg is NULL

Jeroen Demeyer added the comment: OK, I closed this without applying the change. It means one extra special case in PEP 580, but it's not a big deal. -- ___ Python tracker <https://bugs.python.org/is

[issue34287] bufferedio.c uses unused argument of METH_NOARGS functions

New submission from Jeroen Demeyer : A METH_NOARGS function has a second unused argument which is always NULL (this is guaranteed by the documentation). However, some functions in Modules/_io/bufferedio.c actually that second NULL argument. This is technically not a bug, but it looks more

[issue34287] bufferedio.c uses unused argument of METH_NOARGS functions

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +8091 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34287> ___ ___ Py

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

Jeroen Demeyer added the comment: > For compatibility with extensions built with older Pythons you should define > new type flag and read tp_fastcall only if the flag is set. Can you comment on https://github.com/python/cpython/pull/4944 why you think that such compatibility sho

[issue29502] Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro?

Jeroen Demeyer added the comment: I always assumed that enabling profiling only from the Python bytecode interpreter was a deliberate choice. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue29

[issue34211] Cygwin build broken due to use of &PyType_Type in static declaration in _abc module

Jeroen Demeyer added the comment: For those who are not very aware of Cygwin issues: what is wrong with PyVarObject_HEAD_INIT(&PyType_Type, 0); -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/iss

[issue34211] Cygwin build broken due to use of &PyType_Type in static declaration in _abc module

Jeroen Demeyer added the comment: Linker issues are always tricky... I understand that there is no problem within libpython, so the questions below refer to extension modules. I am asking them from the point of view of somebody writing Python extension modules who is clueless about Cygwin

[issue29502] Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro?

Jeroen Demeyer added the comment: I would prefer to wait with this issue until PEP 580 has been decided. If it's accepted, it will change function calling code a lot. As I wrote in PEP 580, I was planning to have a PEP on profiling a

[issue34126] Profiling certain invalid calls crashes Python

Change by Jeroen Demeyer : -- resolution: -> fixed status: open -> closed ___ Python tracker <https://bugs.python.org/issue34126> ___ ___ Python-bugs-list

[issue32773] distutils should NOT preserve timestamps

Jeroen Demeyer added the comment: I started a discussion at https://mail.python.org/mm3/archives/list/distutils-...@python.org/thread/4FHEGHZYWCDRWVPGYLAU5VUS5BAX73MO/ -- ___ Python tracker <https://bugs.python.org/issue32

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > Then instead of adding the source directory to sys.path What's wrong with that? Installing the .pyx sources together with the .so compiled modules makes a lot of sense to me: it is very analogous to installing the .py sources together with the .

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > In my view (and that of the documentation for sys.path), sys.path is where > you put things that the Python interpreter can load - .so files, .pyc files > and .py files. It's quite typical for packages to install stuff in site-pack

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: To everybody who mentioned that Cython sources don't belong on sys.path: where *do* they belong then? One issue which hasn't been mentioned before is packaging. By installing Cython sources along with the generated .so files, we can re-use all th

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > In a subdirectory similar to __pycache__. I thought about that, but I don't like the idea because then the directory structure of the actual sources would be different from the directory structure of the installed sources. So for example, how sho

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: Nick: do you agree that this "source-only metapath" should by default contain an entry to look in sys.path for source files? -- ___ Python tracker <https://bugs.python.o

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > Keeping two identical package structures in different places, one for .py > files and generated .so files, and one for Cython source files (.pyx, .pxd, > .pxi), is not desirable from a user perspective, and would require namespace > pack

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > The one possible fly in the ointment is if there are use cases that we need to support where a single .so/.pyd file is built from *multiple* source files, as get_source doesn't allow for that. Yes, we must support that. A cython module may have

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > So, where is the filename coming from? Python 3.7.0 (default, Jul 23 2018, 10:07:21) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from sage.all

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > Now, though, we need a way for SageMath to get it working on releases up to > and including 3.7, *without* any help from Cython or CPython That's not really what I need. We already have a work-around in SageMath: try: from importlib.machi

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > One other thing I will say is that the PEP 302 APIs were seemingly designed > for working with Python source and were not necessarily oriented towards > alternative code representations that were executed That's also my impression. I'm

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > If you're OK with that, I don't see the problem. I recall that we already agreed several months ago, when I submitted https://github.com/python/cpython/pull/6653 -- ___ Python tracker <https:/

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: I just realized the existence of https://docs.python.org/3/library/importlib.html#importlib.abc.ResourceReader Isn't this *exactly* what we need here? -- ___ Python tracker <https://bugs.python.org/is

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: I think I could make linecache use the ResourceReader API to find the source file instead of looking in the sys.path entries. However, that's orthogonal to PR 6653: we still need PR 6653 to continue looking for the source file in the first

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > I would love, for example, to be able to get stack traces within extension > modules integrated into Python tracebacks if they are compiled with some > appropriate debug flags. Awesome idea, I want to work on that :-) This should be possible

[issue32797] Tracebacks from Cython modules no longer work

Jeroen Demeyer added the comment: > Or, define a new "get_sourcemap()" method that could return additional > metadata, e.g. a line number mapping. What's your use case for that? I am asking because it might make more sense for get_source() (or whatever its replacem

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

Change by Jeroen Demeyer : -- pull_requests: +8542 ___ Python tracker <https://bugs.python.org/issue25750> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue34125] Profiling depends on whether **kwargs is given

Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue34751] Hash collisions for tuples

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

[issue34751] Hash collisions for tuples

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

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: > ISTM, you're being somewhat aggressive and condescending. Interestingly, I felt the same with your reply, which explains my rapid reversion of your closing of the ticket. The way I see it: I pointed out a bug in tuple hashing and you just clo

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: > Since I don't believe we've had other reports of real-life pathologies since You just did in this bug report. Why doesn't that count? -- ___ Python tracker <https://bugs.

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: To come back to the topic of hashing, with "Bernstein hash" for tuples I did indeed mean the simple (in Python pseudocode): # t is a tuple h = INITIAL_VALUE for x in t: z = hash(x) h = (h * MULTIPLIER) + z return h I actually started work

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: For the record: my collision is not contrived. It came up in actual code where I was hashing some custom class using tuples and found an unexpected high number of collisions, which I eventually traced back to the collision I reported here. By the way, I

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: > So, jdemeyer, if it's possible to show (or describe) to us an example of a > problem you had, such that we could repeat it, that would be helpful (and > necessary) to evaluate any proposed changes. What were the inputs to hash() > that

[issue34751] Hash collisions for tuples

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +8884 stage: resolved -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: I should also make it clear that the collision hash((1,0,0)) == hash((1,-2,-2)) that I reported is due to the algorithm, it's not due to some bad luck that 2 numbers happen to be the same. There are also many more similar hash collisions for tuples

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: > Further, that example specifically exploits that "hash(-1) == hash(-2)" No, it does not. There is no hashing of -1 involved in the example hash((1,0,0)) == hash((1,-2,-2)). -- ___ Python tr

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: > FWIW, the current algorithm also has some advantages that we don't want to > lose. In particular, the combination of the int hash and tuple hash are good > at producing distinct values for non-negative numbers: >>> from i

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: Concerning the MULTIPLIER: > Why do you claim the original was "too small"? Too small for what purpose? If the multiplier is too small, then the resulting hash values are small too. This causes collisions to appear for smaller numbers: BEFORE

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: I pushed a minor update to the PR, changing the MULTIPLIER and explaining the chosen constants. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: > I don't know that primes are important here, but neither do I know that > they're _not_ important here. Hashes are effectively computed modulo 2**N. "Primes" are meaningless in that setting (except for the prime 2 which does ha

<    1   2   3   4   5   6   7   >