[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: A (simplified and slightly modified version of) xxHash seems to work very well, much better than SeaHash. Just like SeaHash, xxHash also works in parallel. But I'm not doing that and just using this for the loop: for y in t: y ^= y * (PRIME32_2 -

[issue34883] test_lzma: Multiple test failures when liblzma is built without complete codec set

New submission from Michał Górny : xz-utils has four options to configure codecs supported by liblzma: --enable-encoders --enable-decoders --enable-match-finders --enable-checks In Gentoo, we're using those options to optionally provide smaller footprint liblzma builds that include onl

[issue34880] About the "assert" bytecode

thautwarm added the comment: Reply to this: > How is that different from every other case of shadowing a builtin? > > len = 45 > print(len("hello world")) ``` AssertionError = 42 assert 1 != 2 ``` `assert` implicitly invokes `AssertionError`, while `len` does that explicitly. That is to sa

[issue34876] Python3.8 changes how decorators are traced

Ned Batchelder added the comment: Yes, I agree that the assignment statement behavior is fine. The stacked decorator behavior is not. I understand that under the hood the two cases are very similar, but the syntax is different. Jumping back to the first decorator makes it look like the de

[issue34880] About the "assert" bytecode

Steven D'Aprano added the comment: On Wed, Oct 03, 2018 at 09:49:06AM +, thautwarm wrote: > Steven, this problem is quite interesting because it just allows users > to cause fatal errors without any invalid operations. How is that different from every other case of shadowing a builtin? l

[issue34876] Python3.8 changes how decorators are traced

Serhiy Storchaka added the comment: I think this is a correct behavior. $ cat -n multiline_assignment.py 1 x = 1 2 y = 2 3 z = [ 4 x, 5 y, 6 ] $ ./python -m trace --trace multiline_assignment.py In 3.7 the line with the assignment is missed: ---

[issue34880] About the "assert" bytecode

thautwarm added the comment: If we could generate `LOAD_CONST` instructions for `assert` statements, any prospective dangers could be avoided. ``` from dis import dis @dis def f(): assert x 3 0 LOAD_GLOBAL 0 (x) 2 POP_JUMP_IF_TRUE 8

[issue34880] About the "assert" bytecode

thautwarm added the comment: Steven, this problem is quite interesting because it just allows users to cause fatal errors without any invalid operations. ``` AssertionError = 1 assert 1 == 2, 2 --- TypeError: 'int' object

[issue34711] Lib/http/server.py: Return HTTPStatus.NOT_FOUND if path.endswith(/) and not a directory

Change by Michael Felt : -- pull_requests: +9073 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue34711] Lib/http/server.py: Return HTTPStatus.NOT_FOUND if path.endswith(/) and not a directory

Michael Felt added the comment: Closed "test" version. made new PR that makes server.py conform to Issue17234 demands -- components: +Library (Lib) -Tests title: Fix test_httpservers on AIX (trailingSlashOK) -> Lib/http/server.py: Return HTTPStatus.NOT_FOUND if path.endswith(/) and n

[issue34876] Python3.8 changes how decorators are traced

Ned Batchelder added the comment: Are we sure this is the behavior we want? Now when I step through your code in the debugger, it will show me line 2, then 3, then 4, then 2 again. I can see the appeal for a multiline assignment statement, but for stacked decorators it just seems wrong. ---

[issue34882] f(a=1, *args) should be a SyntaxError

Serhiy Storchaka added the comment: See the thread "Order of positional and keyword arguments" on the Python-Dev mailing lists at 2018-04-26: https://mail.python.org/pipermail/python-dev/2018-April/153157.html -- nosy: +gvanrossum, serhiy.storchaka __

[issue34014] loop.run_in_executor should propagate current contextvars

Andrew Svetlov added the comment: I vote on not changing `run_in_executor` behavior if we cannot make it work with `ProcessPoolExecutor`. If a new API will solve the problem -- that's fine. Until it landed the explicit context propagation is the satisfactory solution. -- ___

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: I'm having a look at xxHash, the second-fastest hash mentioned on https://docs.rs/seahash/3.0.5/seahash/ -- ___ Python tracker ___ _

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

tzickel added the comment: Its ok, you only did it twice :) I've submitted a manual 2.7 fix on GH. -- ___ Python tracker ___ ___ Py

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

Change by tzickel : -- pull_requests: +9072 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue34751] Hash collisions for tuples

Jeroen Demeyer added the comment: > I know of no such hash functions short of crypto-strength ones. Being crypto-strength and having few collisions statistically are different properties. For non-crypto hash functions it's typically very easy to generate collisions once you know the paramet

[issue34784] Heap-allocated StructSequences

Josh Rosenberg added the comment: This looks like a duplicate of #28709, though admittedly, that bug hasn't seen any PRs. -- nosy: +josh.r ___ Python tracker ___

[issue34882] f(a=1, *args) should be a SyntaxError

New submission from metaxm : >>> def f(a, b, c): ... pass >>> f(a=1, 2, 3) SyntaxError: positional argument follows keyword argument >>> f(a=1, *(2, 3)) TypeError: f() got multiple values for argument 'a' f(a=1, 2, 3) will cause a SyntaxError, but f(a=1, *(2, 3)) will cause a TypeError. T

[issue34880] About the "assert" bytecode

Steven D'Aprano added the comment: If I have understood you correctly, you are asking whether it is expected behaviour for assert to use the global AssertionError instead of the built-in AssertionError. I don't see why it shouldn't. In any case, that behaviour goes back to Python 1.5 and pe

[issue34881] unnecessary encoded-words usage breaks DKIM signatures

New submission from Bryce Drennan : Since Python 3.6.4 folding of unstructured headers uses the encoded words syntax even if there are no special characters. This makes DKIM-Signature headers that are unreadable to google's gmail servers. It may be that encoded-words are not valid in this h

<    1   2