[issue44392] Py_GenericAlias is not documented

Ronald Oussoren added the comment: I'm not working on this. Feel free to work on a PR. -- ___ Python tracker ___ ___ Python-bugs-li

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: > I mention the QueryPerformanceFrequency error case here (stack misalignment): > https://bugs.python.org/issue41299#msg395237 Do you think that pytime.c has the bug? I don't think so. > There are three places win_perf_counter_frequency() can fail: > https:

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: I'm fine with adding _PyTime_Init() again, and maybe only implement checks on Windows. On Linux, I only saw a single failure in _PyTime_Init() once, when Python was run in a sandbox, and the time syscalls were not allowed. It was a corner case about the new

[issue37224] [subinterpreters] test__xxsubinterpreters fails randomly

Change by Roundup Robot : -- nosy: +python-dev nosy_count: 6.0 -> 7.0 pull_requests: +25305 pull_request: https://github.com/python/cpython/pull/26717 ___ Python tracker ___ __

[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring

Change by Irit Katriel : -- versions: +Python 3.11 -Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44417] bytecode<>line number mapping seems wrong in 3.10.0b2

New submission from Gabriele N Tornetta : I was looking at how the new co_linetable works in order to add initial support for Python 3.10 to Austin (https://github.com/P403n1x87/austin) when I stumbled upon the following interesting output from the dis module. I am using the following test ta

[issue44338] Port LOAD_GLOBAL to adaptive interpreter

Mark Shannon added the comment: New changeset eecbc7c3900a7f40d8498b151db543a202c72f74 by Mark Shannon in branch 'main': bpo-44338: Port LOAD_GLOBAL to PEP 659 adaptive interpreter (GH-26638) https://github.com/python/cpython/commit/eecbc7c3900a7f40d8498b151db543a202c72f74 -- _

[issue44415] sys.stdout.flush and print() hanging

Rajeev Chaurasia added the comment: self.logger = lib.logger.Log() We have cronjob entry to call the application everyday $crontab -e 0 1 * * * /scratch/rajeev/cronjob/exachk.sh exachk.sh makes call to my python application as- python3 /opt/oracle.ahf/exachk/exachk.py Yes I am redirecting st

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: > It shouldn't behave drastically different just because the user closed the > laptop lid for an hour I talked to someone who's been helping with the Go time APIs and it seems like that holds pretty well for interactive timeouts, but makes no sense for network

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: > Does this change need to be mentioned in What's New? Yes, I think so, given that it's a change to documented behavior. It's also something that third party packages (like NumPy) potentially need to be aware of. --

[issue44328] time.monotonic() should use a different clock source on Windows

Eryk Sun added the comment: > Seems like Windows 7 may need to be considered as well, as > per vstinner's bpo-32592 mention? Python 3.9 doesn't support Windows 7. Moreover, the interpreter DLL in 3.9 implicitly imports PathCchCanonicalizeEx, PathCchCombineEx, and PathCchSkipRoot, which were

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Ryan Hileman added the comment: Perhaps the simplest initial fix would be to move that check down to PyThread__init_thread() in the same file. I'm not sure what the cpython convention for that kind of init error is, would it just be the same Py_FatalError block or is there a better pattern?

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Ryan Hileman added the comment: I agree with not throwing fatal errors, but that check is unlikely to actually be hit, and you removed the startup checks covering the underlying clocks here: https://github.com/python/cpython/commit/ae6cd7cfdab0599139002c526953d907696d9eef I think if the time

[issue44416] test_threading: test_print_exception() hangs and killed after 3h15 on AMD64 Windows8.1 Refleaks 3.9

Change by STINNER Victor : -- title: test_threading: test_print_exception() hangs and killed after 3h15 -> test_threading: test_print_exception() hangs and killed after 3h15 on AMD64 Windows8.1 Refleaks 3.9 ___ Python tracker

[issue44416] test_threading: test_print_exception() hangs and killed after 3h15

New submission from STINNER Victor : AMD64 Windows8.1 Refleaks 3.9: https://buildbot.python.org/all/#/builders/6/builds/48 4:03:35 load avg: 3.98 [425/425/1] test_threading crashed (Exit code 1) beginning 6 repetitions 123456 Timeout (3:15:00)! Thread 0x0748 (most recent call first): File

[issue44409] compile raises SyntaxError with undocumented lineno attribute None

Florian Weimer added the comment: I suppose changing the documentation to mention `None` would be possible as well, but restoring the old behavior works for me too. Thanks. -- ___ Python tracker ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: I suggest to remove the (now <= 0) check. _PyTime_t now = _PyTime_GetPerfCounter(); if (now <= 0) { Py_FatalError("_PyTime_GetPerfCounter() == 0"); } Please don't add such Py_FatalError() in the middle of a function. If thi

<    1   2