[issue27647] Update Windows build to Tcl/Tk 8.6.6

Terry J. Reedy added the comment: AFAIK, the Windows x.y compiled release and installer is normally updated to the latest stable tcl/tk, about the time of beta 1, and never changed for bugfix releases. 2.7 was an exception because of its long life and because later 8.5.z releases has some

[issue29411] Option --executable for entry_points

New submission from Michal Cyprian: 1. python3 setup.py build --executable="/usr/bin/binary" 2. python3 setup.py install -O1 --skip-build These two commands are typically used to build and install Python packages from sources. Let's assume there is a setup.py script of package foo, containing

[issue29402] Problem with Checkbutton and duplicate last name components

Serhiy Storchaka added the comment: The variable option of the checkbutton widget specifies the name of a global variable to set to indicate whether or not this button is selected. It defaults to the name of the button within its parent (i.e. the last element of the button window's path

[issue29410] Moving to SipHash-1-3

Marc-Andre Lemburg added the comment: On 01.02.2017 11:07, Serhiy Storchaka wrote: > > The performance of hash algorithm shouldn't affect general benchmarks since > hash value is cached inside string object. Almost all dict lookups in > critical parts are lookups with interned strings. But in

[issue29410] Moving to SipHash-1-3

Marc-Andre Lemburg added the comment: On 01.02.2017 10:50, INADA Naoki wrote: > >> it seems as if it would make sense to not use a fixed >> hash algorithm for all strings lengths, but instead a >> hybrid one to increase performance for short strings >> (which are used a lot in Python). >> >> Is

[issue29404] "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray

Changes by Serhiy Storchaka : -- nosy: +benjamin.peterson, skrah ___ Python tracker ___

[issue29410] Moving to SipHash-1-3

Serhiy Storchaka added the comment: The performance of hash algorithm shouldn't affect general benchmarks since hash value is cached inside string object. Almost all dict lookups in critical parts are lookups with interned strings. But in corner cases the difference can be measurable. We

[issue29410] Moving to SipHash-1-3

INADA Naoki added the comment: > it seems as if it would make sense to not use a fixed > hash algorithm for all strings lengths, but instead a > hybrid one to increase performance for short strings > (which are used a lot in Python). > > Is there a good hash algorithm with provides better >

Re: [issue29410] Moving to SipHash-1-3

On 01.02.2017 10:14, Christian Heimes wrote: > > PEP 456 defines an API to add more hashing algorithms and make the selection > of hash algorithm a compile time option. We can easily add SipHash-1-3 and > make it the default algorithm. Vendors then can select between FNV2, > SipHash-1-3 and

[issue29410] Moving to SipHash-1-3

Christian Heimes added the comment: I added SipHash13 as additional hash algorithm in https://github.com/tiran/cpython/tree/siphash13 . Still need to verify the finalizer. For hashlib I'd need to move to a different implementation of SipHash. The implementation in pyhash.c is optimized for

[issue29377] Add the 'wrapper_descriptor' type to the types module

Ivan Levkivskyi added the comment: Guido, I attach the full patch now, as you asked. (Initially I was not sure about tests, but now I understand more these types, so that I added even few more tests than in original patch) > Maybe we need to wait for the github migration to complete though?

[issue29397] linux/random.h present but cannot be compiled

Chi Hsuan Yen added the comment: Could you upload a copy of config.log? Also added developers that play in random.h games -- components: +Build nosy: +Chi Hsuan Yen, benjamin.peterson, haypo ___ Python tracker

[issue29410] Moving to SipHash-1-3

INADA Naoki added the comment: > PEP 456 defines an API to add more hashing algorithms and make the selection > of hash algorithm a compile time option. We can easily add SipHash-1-3 and > make it the default algorithm. Vendors then can select between FNV2, > SipHash-1-3 and SipHash-2-4. OK,

[issue29410] Moving to SipHash-1-3

INADA Naoki added the comment: $ ../python.default -m perf compare_to default.json patched4.json -G Slower (2): - scimark_sor: 479 ms +- 8 ms -> 485 ms +- 9 ms: 1.01x slower (+1%) - genshi_xml: 196 ms +- 2 ms -> 196 ms +- 2 ms: 1.00x slower (+0%) Faster (19): - json_loads: 62.7 us +- 0.5 us ->

[issue29410] Moving to SipHash-1-3

Christian Heimes added the comment: PEP 456 defines an API to add more hashing algorithms and make the selection of hash algorithm a compile time option. We can easily add SipHash-1-3 and make it the default algorithm. Vendors then can select between FNV2, SipHash-1-3 and SipHash-2-4. On

[issue29377] Add the 'wrapper_descriptor' type to the types module

Manuel Krebber added the comment: One question I was wondering about is whether those types should be checked by inspect.isroutine() as well. -- ___ Python tracker

[issue29410] Moving to SipHash-1-3

INADA Naoki added the comment: I'm running pyperformance. BTW, hashlib doesn't provide siphash24. So can we simply replace siphash24 with siphash13, like ruby? https://github.com/ruby/ruby/commit/04c94f95d1a1c6a12f5412228a2bcdc00f5de3b2 -- ___

[issue29398] memory corruption in xxlimited

Changes by Roundup Robot : ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29398] memory corruption in xxlimited

Roundup Robot added the comment: New changeset 24bff360c2aa6d52f7a40ef35a5d7e5660d13402 by Benjamin Peterson in branch '3.5': gc types needs to be allocated as such (closes #29398) https://github.com/python/cpython/commit/24bff360c2aa6d52f7a40ef35a5d7e5660d13402 --

[issue29398] memory corruption in xxlimited

Changes by Roundup Robot : ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29398] memory corruption in xxlimited

Roundup Robot added the comment: New changeset 24bff360c2aa6d52f7a40ef35a5d7e5660d13402 by Benjamin Peterson in branch 'master': gc types needs to be allocated as such (closes #29398) https://github.com/python/cpython/commit/24bff360c2aa6d52f7a40ef35a5d7e5660d13402 New changeset

[issue29398] memory corruption in xxlimited

Changes by Roundup Robot : ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29398] memory corruption in xxlimited

Changes by Roundup Robot : ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29398] memory corruption in xxlimited

Changes by Roundup Robot : ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29398] memory corruption in xxlimited

Changes by Roundup Robot : ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29398] memory corruption in xxlimited

Changes by Roundup Robot : ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29398] memory corruption in xxlimited

Changes by Roundup Robot : ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29398] memory corruption in xxlimited

Roundup Robot added the comment: New changeset 24bff360c2aa6d52f7a40ef35a5d7e5660d13402 by Benjamin Peterson in branch '3.6': gc types needs to be allocated as such (closes #29398) https://github.com/python/cpython/commit/24bff360c2aa6d52f7a40ef35a5d7e5660d13402 New changeset

[issue29398] memory corruption in xxlimited

Changes by Roundup Robot : ___ Python tracker ___ ___ Python-bugs-list mailing list

<    1   2   3