STINNER Victor added the comment:
> Can you please attach the output log of the test?
Since the original reporter didn't reply, we cannot investigate the issue and I
close it. If you still have the issue, please reopen the issue with the full
test output (attached as a f
STINNER Victor added the comment:
I close the issue as out of date, since there is no activity for 4 years. Maybe
it was fixed in the meanwhile.
If it's not the case, please reopen the issue. If someone can still reproduce
the issue, it would help to write a short reproducer script based
STINNER Victor added the comment:
New changeset 679cb4781ea370c3b3ce40d3334dc404d7e9d92b by Victor Stinner in
branch 'main':
bpo-44895: libregrtest: refleak check clears types later (GH-28113)
https://github.com/python/cpython/commit/679cb4781ea370c3b3ce40d3334dc404d7e9d92b
Change by STINNER Victor :
--
keywords: +patch
pull_requests: +26554
pull_request: https://github.com/python/cpython/pull/28113
___
Python tracker
<https://bugs.python.org/issue44
STINNER Victor added the comment:
> I changed dash_R_cleanup to put the sys._clear_type_cache() after
> clear_caches() and the leak is gone
Aha! The order of function calls in dash_R_cleanup() matters.
Calling sys._clear_type_cache() at the end of dash_R_cleanup() perfectly makes
STINNER Victor added the comment:
Christian Tismer: "What about an even more flexible solution? A debug option
could memorize always the last object deallocated and give full info (the
object's repr) before the crash would happen."
Bugs in object_dealloc() are rare. Apart
STINNER Victor added the comment:
> x86-64 macOS 3.10: https://buildbot.python.org/all/#/builders/681/builds/345
On this machine, RLIMIT_NOFILE soft limit is 256.
test.pythoninfo:
resource.RLIMIT_NOFILE: (256, 9223372036854775807)
platform.platform: macOS-11.5.2-x86_64-i386-64
STINNER Victor added the comment:
x86-64 macOS 3.10:
https://buildbot.python.org/all/#/builders/681/builds/345
==
FAIL: test_multiprocessing_pool_circular_import
(test.test_importlib.test_threaded_import.ThreadedImportTests
STINNER Victor added the comment:
Nice!
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue27334>
___
___
Python-bugs-list mailing list
Unsub
STINNER Victor added the comment:
> My use case for these low-level APIs is to write tests for low-level
> string/encoding handling in my custom use of the PyPreConfig and PyConfig
> structs. I wanted to verify that exact byte sequences were turned into
> specific representa
STINNER Victor added the comment:
See also bpo-20443 "__code__. co_filename should always be an absolute path". I
had a revert a change which affected sys.argv[0]:
commit a1a99b4bb7cbe2dbc55a1d92c3c509b4466d3c3b
Author: Victor Stinner
Date: Mon Dec 9 17:34:02 2019 +0100
STINNER Victor added the comment:
> `call(f, *args, **kwargs) == f(*args, **kwargs)`
So you can want to reintroduce the Python 2 apply() function which was removed
in Python 3.
You can reimplement it in 2 lines, no?
def call(func, *args, **kwargs):
return func(*args, **kwa
Change by STINNER Victor :
--
nosy: -vstinner
___
Python tracker
<https://bugs.python.org/issue45042>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
> But there is also an issue in the script itself. It fails or produces a
> mojibake when the filesystem encoding and the stdout encoding do not match.
I don't know Tools/scripts/md5sum.py. Can you show an example which currently
STINNER Victor added the comment:
> I don't follow what you want to change in 3.10.0 final, PEP 657 is for Python
> 3.11. Can you clarify?
Ah, I thaught that the PEP was implemented in 3.10, I didn't notice that it's a
new feature of Python 3.11 :-)
> Regarding the issue: I unders
Change by STINNER Victor :
--
nosy: -vstinner
___
Python tracker
<https://bugs.python.org/issue42064>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
> It could be a problem with the way _Py_RefTotal is incremented/decremented.
It can be a cache which is kept alive and then clear the following iteration.
See my previous comment:
test leaked [-4, 4, -4, 4, -4, 4, -4, 4, -4, 4, -4, 4, -4, 4, -4, 4, -4
Change by STINNER Victor :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
STINNER Victor added the comment:
New changeset 4300352000beed22fb525ec45fd331918d206528 by Victor Stinner in
branch 'main':
bpo-45061: Detect Py_DECREF(Py_True) bug (GH-28089)
https://github.com/python/cpython/commit/4300352000beed22fb525ec45fd331918d206528
STINNER Victor added the comment:
> If we go in this direction we should add a DeprecationWarning for __str__()
> returning not direct str.
I saw str subclass being used for translation. Example:
class Message(str):
"""A Message object is a unicode object t
STINNER Victor added the comment:
New changeset 888d4cc06b887e77f281ba4d640e281cb4c61b7b by Victor Stinner in
branch 'main':
bpo-45061: Enhance faulthandler traceback wit no Python frame (GH-28090)
https://github.com/python/cpython/commit/888d4cc06b887e77f281ba4d640e281cb4c61b7b
STINNER Victor added the comment:
PPC64LE RHEL8 LTO 3.10:
https://buildbot.python.org/all/#/builders/680/builds/279
0:01:14 load avg: 8.67 [236/427/1] test_asyncio failed (env changed) (1 min 5
sec) -- running: test_gdb (1 min 2 sec), test_tokenize (47.0 sec)
Warning -- Unraisable exception
New submission from STINNER Victor :
s390x RHEL8 Refleaks 3.10:
https://buildbot.python.org/all/#/builders/669/builds/121
Reformatted output:
0:19:31 load avg: 2.74 [316/427/1] test_asyncio failed (env changed) (14 min 36
sec) -- running: test_statistics (37.6 sec), test_signal (16 min 51
STINNER Victor added the comment:
I can see the test_typing issue with this patch:
diff --git a/Lib/test/libregrtest/refleak.py b/Lib/test/libregrtest/refleak.py
index b94826a5da..49e5f03414 100644
--- a/Lib/test/libregrtest/refleak.py
+++ b/Lib/test/libregrtest/refleak.py
@@ -124,7 +124,7
STINNER Victor added the comment:
A variant of this problem: bpo-36560 with a leak 1 memory block per iteration.
--
___
Python tracker
<https://bugs.python.org/issue44
STINNER Victor added the comment:
Recent failure on AMD64 Fedora Rawhide Refleaks 3.x:
https://buildbot.python.org/all/#/builders/565/builds/131
test_typing leaked [1, 1, 1] memory blocks, sum=3
(...)
0:46:40 load avg: 0.00 Re-running test_typing in verbose mode
test_typing leaked [1, 1, 1
STINNER Victor added the comment:
I looked at the implementation. It's more complex than what I expected.
tb_displayline(): _Py_DisplaySourceLine() returns the source line with the
indentation, but then it truncates the indentation.
extract_anchors_from_line() includes the indentation if I
New submission from STINNER Victor :
The PEP 657 introduced ^^^ in tracebacks. It is useful when the error happens
on an sub-expression in a long line. Example:
File "/home/vstinner/python/main/Lib/ftplib.py", line 462, in retrlines
with self.transfercmd(cm
STINNER Victor added the comment:
aarch64 Fedora Stable Clang 3.10:
https://buildbot.python.org/all/#/builders/635/builds/253
0:00:23 load avg: 12.40 [404/427/1] test_ftplib failed (env changed)
Warning -- Uncaught thread exception: Exception
Exception in thread Thread-34:
Traceback (most
Change by STINNER Victor :
--
title: test_asyncio: test_huge_content_recvinto() failed -> test_asyncio:
test_huge_content_recvinto() failed on PPC64LE RHEL8 Refleaks 3.9
___
Python tracker
<https://bugs.python.org/issu
New submission from STINNER Victor :
PPC64LE RHEL8 Refleaks 3.9:
https://buildbot.python.org/all/#/builders/482/builds/128
test test_asyncio failed -- Traceback (most recent call last):
File
"/home/buildbot/buildarea/3.9.cstratak-RHEL8-ppc64le.refleak/build/Lib/test/test_as
Change by STINNER Victor :
--
pull_requests: +26533
pull_request: https://github.com/python/cpython/pull/28090
___
Python tracker
<https://bugs.python.org/issue45
STINNER Victor added the comment:
There was such bug in CPython stdlib, in the _testcapi module, see commit
310e2d25170a88ef03f6fd31efcc899fe062da2c of bpo-36854:
commit 310e2d25170a88ef03f6fd31efcc899fe062da2c
Author: Victor Stinner
Date: Fri Nov 22 10:58:00 2019 +0100
bpo-36854
Change by STINNER Victor :
--
pull_requests: +26532
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28089
___
Python tracker
<https://bugs.python.org/issu
STINNER Victor added the comment:
To reproduce the bug, apply attached os_uname_refcount_bug.patch and call
os.uname():
---
$ ./python -c 'import os; os.uname()'
(...)
Fatal Python error: _PyMem_DebugRawFree: bad ID: Allocated using API '',
verified using API 'o
New submission from STINNER Victor :
Writing C extensions using directly the C API is error prone. It's easy to add
or forget a Py_INCREF or Py_DECREF. Adding Py_DECREF(Py_True) or
Py_DECREF(Py_False) by mistake causes a surprising crash at Python exit:
---
Debug memory block at address p
STINNER Victor added the comment:
Is it related to https://bugs.python.org/issue41034 ?
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue44
STINNER Victor added the comment:
> An actual use case I had for such an operator was collecting a bunch of
> callables in a list and wanting to dispatch them to
> concurrent.futures.Executor.map, i.e. something like
> `executor.map(operator.call, funcs)` (to get the parallel
STINNER Victor added the comment:
Python 2.7 had apply(func, args, kwargs) which called func(*args, **kwargs).
https://docs.python.org/2.7/library/functions.html#apply
There is also functools.partial(func, *args, **kwargs)(*args2, **kwargs2) which
calls func(*args, *args2, **kwargs
STINNER Victor added the comment:
> PyUnicode_KIND does *not* expose the implementation details to the programmer.
PyUnicode_KIND() is very specific to the exact PEP 393 implementation.
Documentation of this field:
---
/* Character size:
- PyUnicode_WCHAR_KIND (0):
* character t
STINNER Victor added the comment:
> It's doing this now, so seems like it has been fixed: % env -i ./python.exe
> (...)
Right. It's correct to close the issue.
The PEP 540 added a UTF-8 Mode. This mode is enabled if Python is started with
the "C" or "POSIX"
STINNER Victor added the comment:
> In order to avoid undefined behavior, Python's C API should avoid all use of
> bit fields.
See also the PEP 620. IMO more generally, the C API should not expose
structures, but provide ways to access it through getter and setter functions.
See bpo
STINNER Victor added the comment:
> The macro PyUnicode_KIND is part of the documented public C API.
IMO it was a mistake to expose it as part of the public C API. This is an
implementation detail which should not be exposed. The C API should not expose
*directly* how characters are sto
STINNER Victor added the comment:
> The path is not required to be normalized.
I'm talking about the current implementation.
I'm not against making Python even better: attempt to normalize the path ;-)
--
___
Python tracker
<
STINNER Victor added the comment:
test_sys:
def test_executable(self):
# sys.executable should be absolute
self.assertEqual(os.path.abspath(sys.executable), sys.executable)
IMO the test is wrong. It must test:
test.assertTrue(os.path.isabs(sys.executable)).
The path
STINNER Victor added the comment:
For the very specific case of os.environ.clear(), the C function clearenv()
could be used if available.
While clearenv() is available in the glibc, it's not a POSIX function.
--
___
Python tracker
<ht
STINNER Victor added the comment:
> At least the PyASCIIObject struct in Include/cpython/unicodeobject.h uses bit
> fields. Various preprocessor macros like PyUnicode_IS_ASCII() and
> PyUnicode_KIND() access this struct's bit field.
What is your use case? Which functions do you n
STINNER Victor added the comment:
On my Fedora 34, running ./configure creates pyconfig.h with these values:
$ grep -E '_POSIX_C_SOURCE|_XOPEN_SOURCE' -B1 pyconfig.h
/* Define to activate features from IEEE Stds 1003.1-2008 */
#define _POSIX_C_SOURCE 200809L
--
/* Define to the level of X
STINNER Victor added the comment:
Attached set_unset_env.c program calls putenv("=hello world") and then
unsetenv("").
On my Fedora 34 with glibc-2.33-20.fc34.x86_64, putenv() succeed, but
unsetenv() fails.
---
$ gcc set_unset_env.c -g -o set_unset_env && ./
STINNER Victor added the comment:
By the way:
---
The env command from GNU coreutils supports setting the environment variable
with an empty name but not unsetting it. That's a bug.
$ env '=wibble' env |grep wibble
=wibble
$ env '=wibble' env -u '' env
env
STINNER Victor added the comment:
The following command still fails on the Python main branch on Linux:
---
$ env -i =value ./python -c 'import pprint, os; pprint.pprint(os.environ); del
os.environ[""]'
environ({'': 'value', 'LC_CTYPE': 'C.UTF-8'})
Traceback (most recent call las
Change by STINNER Victor :
--
nosy: -vstinner
___
Python tracker
<https://bugs.python.org/issue45021>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
I don't understand anything about multiprocessing, nor its API, but some people
seem to find it useful :-D I remove myself from the nosy list ;-)
--
___
Python tracker
<https://bugs.python.org/issue45
STINNER Victor added the comment:
The bug should now be fixed in 3.9 and 3.10 branches.
The main branch should not be impacted, it has a different implementation.
Thanks for the bug report Duncan Grisby.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
STINNER Victor added the comment:
I created https://python-security.readthedocs.io/vuln/expat-billion-laughs.html
to track this vulnerability.
--
___
Python tracker
<https://bugs.python.org/issue44
STINNER Victor added the comment:
Thanks Irit for making progress on this annoying old C API!
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue44
STINNER Victor added the comment:
New changeset fe997e1a67835a929705c8c305d41c4d7dd326e3 by Victor Stinner in
branch '3.10':
bpo-9: faulthandler don't modify frame refcnt (GH-27850)
https://github.com/python/cpython/commit/fe997e1a67835a929705c8c305d41c4d7dd326e3
STINNER Victor added the comment:
Can you please try to convert your patch into a GitHub pull request?
--
___
Python tracker
<https://bugs.python.org/issue44
Change by STINNER Victor :
--
keywords: +patch
pull_requests: +26310
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27850
___
Python tracker
<https://bugs.python.org/issu
Change by STINNER Victor :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.or
STINNER Victor added the comment:
You can also play with the clear() method of frame objects and
traceback.clear_frames() (which expects a traceback object).
--
___
Python tracker
<https://bugs.python.org/issue44
STINNER Victor added the comment:
> test leaked [-4, 4, -4] references, sum=-4
If I disable the GC, the script no longer detects "leaks". Same using a GC
threshold of 800.
Using a GC threshold between 100 and 700, I reproduce the [-4, 4, -4]
references lea
STINNER Victor added the comment:
Irit: do you still reproduce the issue using gc.disable()? Or you can try
different values to call gc.set_threshold(). You may also try different values
in ns.huntrleaks, like: ns.huntrleaks = (3, 20, 'tt_out.py'). With 20
iterations, do you still reproduce
STINNER Victor added the comment:
I ran the test manually on the buildbot worker. Sometimes, the test process
gets the EIO error even before getting the 2 newline bytes (b"\r\n"). I wrote
PR 27813 to simply not expect the newline character.
Adding flush=True to the print("
Change by STINNER Victor :
--
keywords: +patch
pull_requests: +26278
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27813
___
Python tracker
<https://bugs.python.org/issu
STINNER Victor added the comment:
I failed to reproduce the issue on Fedora 34 (readline-8.1-2.fc34.i686).
$ ./python -m test test_readline -m test_auto_history_disabled -j40 -F
(...)
0:19:35 load avg: 42.40 [10785] test_readline passed
0:19:35 load avg: 42.40 [10786] test_readline passed
0
Change by STINNER Victor :
--
title: test_readline: test_auto_history_disabled() fails on aarch64 RHEL8
Refleaks 3.9, 3.10 and 3.x -> test_readline: test_auto_history_disabled() fails
randomly on aarch64 RHEL8 Refleaks 3.9, 3.10 and 3.x
___
Pyt
New submission from STINNER Victor :
test_readline fails randomly on aarc64 RHEL8 buildbots (3.9, 3.10 and 3.x).
In some builds, test_readline fails but then pass when re-run in verbose mode.
Example:
https://buildbot.python.org/all/#/builders/41/builds/148
---
0:02:56 load avg: 2.79 Re
STINNER Victor added the comment:
PyStructSequence_InitType2() is not compatible with subinterpreters: it uses
static types. Moreover, it allocates tp_members memory which is not released
when the type is destroyed. But I'm not sure that the type is ever destroyed,
since this API
STINNER Victor added the comment:
_Py_DumpTracebackThreads() should not use Py_DECREF(). It's a bug. It must only
*read* memory, not *modify* memory since it's called from a signal handler.
It's a regression in dump_traceback().
Python 3.9 and 3.10 use:
frame = PyThreadState_GetFrame
STINNER Victor added the comment:
The machine was busy when test_concurrent_futures: system load of 5.59.
2021-08-16T17:14:01.3805500Z 0:01:58 load avg: 5.59 [ 93/428/1]
test_concurrent_futures failed (2 failures) (1 min 49 sec) -- running:
test_regrtest (39.2 sec
STINNER Victor added the comment:
In another commit of the same PR 27774, I don't even see test_regrtest in the
list of the "10 slowest tests", so test_regrtest took less than "test_socket:
46.4 sec".
If test_regrtest is killed after 20 minutes, it's likely that it
Change by STINNER Victor :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue44936>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by STINNER Victor :
--
nosy: +erlendaasland, lukasz.langa, pablogsal
___
Python tracker
<https://bugs.python.org/issue44937>
___
___
Python-bugs-list m
STINNER Victor added the comment:
> AssertionError: Process return code is 3221225477
> (...)
> AssertionError: Process return code is 3221225477
This is STATUS_ACCESS_VIOLATION: the process crashed, not good :-(
Moreover, even if the process was run with -X faulthandler, stderr
STINNER Victor added the comment:
Recent failure on GHA Windows x64:
https://github.com/python/cpython/runs/3342514542
2021-08-16T17:19:58.4338049Z
==
2021-08-16T17:19:58.4339129Z FAIL
New submission from STINNER Victor :
GitHub Action Windows x64 CI:
https://github.com/python/cpython/runs/3342514542
First, test_regrtest was killed after 20 minutes, while it was running
test_tools_script_run_tests(). Then, re-running test_regrtest in verbose mode
failed
New submission from STINNER Victor :
GitHub Action Windows x64:
https://github.com/python/cpython/runs/3342514542
test_concurrent_futures failed when tests are run in parallel, but then passed
then re-run in verbose mode
STINNER Victor added the comment:
Chris:
> Out of curiosity, is the failure deterministic in environments where it
> fails? If not, what is the source of the indeterminism -- some kind of race
> condition or something else?
The GC uses counters and thresholds to decide which c
STINNER Victor added the comment:
> I see it on Mac but not windows.
Aha, maybe there is something specific on Mac which triggers an exact code path
to trigger to bug. I already saw bugs like that.
You can try to play with gc.set_threshold() to change how garbage collection is
trigge
STINNER Victor added the comment:
> Victor, if the …cycle2 test is hanging then you need the change in PR27626.
That's the commit d5c217475c4957a8084ac3f92ae012ece5edc7cb. My main branch is
up to date (commit 8ac0886091c27bf4b6bb0a9b571e174b554d31a4), it includes the
com
STINNER Victor added the comment:
I am not more lucky in the main branch. I ran it for 30 minutes and it didn't
fail.
$ ./python -m test -R 3:3 test_exceptions -m
test_no_hang_on_context_chain_cycle2 -m
test_recursion_normalizing_infinite_exception -m
test_recursion_in_except_handler -m
STINNER Victor added the comment:
I fail to reproduce the issue on Linux on the 3.10 branch. I interrupted the
job after 20 minutes:
$ ./python -m test -R 3:3 test_exceptions -m
test_no_hang_on_context_chain_cycle2 -m
test_recursion_normalizing_infinite_exception -m
Change by STINNER Victor :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue44895>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
The problem of PyObject_GC_UnTrack() is just the most visible effect of the
trashcan mecanism: tp_dealloc can be called twice, and this is *not* expected
by the tp_dealloc API.
Putting trashcan mecanism outside tp_dealloc can allow to make sure
STINNER Victor added the comment:
I change the issue type to security. The bug can be abused to send emails to
the wrong email address.
--
nosy: +vstinner
type: behavior -> security
___
Python tracker
<https://bugs.python.org/issu
STINNER Victor added the comment:
> Now, any object that uses the trashcan *must* be a GC object.
It would be nice to add an assertion in _PyTrash_begin().
--
___
Python tracker
<https://bugs.python.org/issu
Change by STINNER Victor :
--
title: Consider integration of GC_UNTRACK with TRASHCAN -> Consider integration
of PyObject_GC_UnTrack() with the trashcan C API
___
Python tracker
<https://bugs.python.org/issu
STINNER Victor added the comment:
Moreover, before making any change, I would suggest by starting with
documenting the existing trashcan C API. Right now, there is no documentation
in Doc/c-api/. Documentation can be copied from Include/cpython/object.h.
Last year, I modified the trashcan
STINNER Victor added the comment:
Please don't add new macros. The TRASHCAN C API is already complex enough.
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue44
STINNER Victor added the comment:
Thanks for the fix Augusto Goulart and Pablo! I close the issue.
Pablo asked in PR 27678 if a Python 3.8 Release Manager (Lukasz) wants a
backport to 3.8.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
STINNER Victor added the comment:
New changeset d6d2d549972422ccc6fa335ebf9907e4b3d71817 by Miss Islington (bot)
in branch '3.10':
bpo-33930: Fix segfault with deep recursion when cleaning method objects
(GH-27678) (GH-27719)
https://github.com/python/cpython/commit
STINNER Victor added the comment:
New changeset 15f0a45b2822607f2c38685a72d06f050e24b215 by Miss Islington (bot)
in branch '3.9':
bpo-33930: Fix segfault with deep recursion when cleaning method objects
(GH-27678) (GH-27720)
https://github.com/python/cpython/commit
STINNER Victor added the comment:
It's documented at:
https://docs.python.org/dev/library/types.html#types.CodeType.replace
--
___
Python tracker
<https://bugs.python.org/issue44
STINNER Victor added the comment:
sys.platlibdir was introduced to install libraries in /usr/lib64 rather than
/usr/lib. I'm not sure if it should be used to install libraries in
$HOME/.local/lib64 rather than $HOME/.local/lib. Previously, Fedora already
used $HOME/.local/lib and $HOME
STINNER Victor added the comment:
tongxiaoge: Without more information, we cannot help you. See Christian's
questions.
--
___
Python tracker
<https://bugs.python.org/issue44
STINNER Victor added the comment:
Correctness matters more than performance for 1 nanosecond. IMO a fix like
attached bpo-33930.patch looks like the good approach to fix the crash.
--
___
Python tracker
<https://bugs.python.org/issue33
STINNER Victor added the comment:
AMD64 FreeBSD Shared 3.x is back to green:
test_os.test_get_set_inheritable_o_path() now pass on FreeBSD CURRENT ;-) My
fix works as expected. I simply used the same fix than for Linux.
--
___
Python tracker
STINNER Victor added the comment:
Fixed by bpo-41686:
commit 0ae323b87f1bed64a7fa70f5a41a5800aca032cc
Author: Victor Stinner
Date: Tue Nov 17 18:15:20 2020 +0100
bpo-41686: Always create the SIGINT event on Windows (GH-23344)
bpo-41686, bpo-41713: On Windows, the SIGINT event
STINNER Victor added the comment:
PyType_GetName() is a nice addition, thanks.
--
___
Python tracker
<https://bugs.python.org/issue42035>
___
___
Python-bug
1901 - 2000 of 34965 matches
Mail list logo
