[issue1170] shlex have problems with parsing unicode

wombat added the comment: The error messages may have gone away, but the underlying unicode limitations I mentioned remain: Suppose you wanted to use shlex to build a parser for Chinese text. Would you have to set "wordchars" to a string containing every possible Chinese character? I mysel

[issue1170] shlex have problems with parsing unicode

STINNER Victor added the comment: > I would like to suggest making this change (or something similar) to the > official version of "shlex.py". Would sending an email to > "python-id...@python.org" be a good place to make this proposal? Yes, python-ideas is a good place to start discussion s

[issue45308] multiprocessing default fork child process will not free object, which is inherited from parent process

STINNER Victor added the comment: > I still have some questions about is The Python bug tracker is not a forum for asking help how to use Python. Please stop reopening this issue. -- resolution: -> not a bug status: open -> closed ___ Python trac

[issue1170] shlex have problems with parsing unicode

Andrew Jewett added the comment: After posting that, I noticed that the second example I listed in my previous post (a language where words contain any non-whitespace, non-parenthesis character) can now be implemented in the current version of shlex.py by setting ​"whitespace_true" and "punct

[issue1170] shlex have problems with parsing unicode

Andrew Jewett added the comment: Alright. I'll think about it a little more and post my suggestion there, perhaps. Thanks Victor. -- ___ Python tracker ___ _

[issue36819] Crash during encoding using UTF-16/32 and custom error handler

STINNER Victor added the comment: > We could just forbid error handlers returning position not in the range > (start , end] Yeah, that sounds like a reasonable solution. I don't see the point of returning a position outside this range. What would be the use case? For me, the only corner cas

[issue45316] [C API] Functions not exported with PyAPI_FUNC()

New submission from STINNER Victor : The Python C API contains multiple functions which are not exported with PyAPI_FUNC() and so are not usable. Public functions: --- void PyLineTable_InitAddressRange(const char *linetable, Py_ssize_t length, int firstlineno, PyCodeAddressRange *range); int

[issue45201] API function PySignal_SetWakeupFd is not exported and unusable

STINNER Victor added the comment: See also bpo-45316: [C API] Functions not exported with PyAPI_FUNC(). -- nosy: +vstinner ___ Python tracker ___ _

[issue40642] Cpython "pystate.h" subdirectory wrong

STINNER Victor added the comment: Having two header files with the same name in two directories which are part of the include directories is causing issues like this one :-( For the internal C API, I solve the issue by adding "pycore_" prefix to filenames. Maybe pystate.h should be renamed

[issue36819] Crash during encoding using UTF-16/32 and custom error handler

Marc-Andre Lemburg added the comment: Looking at the specs in PEP 293 (https://www.python.org/dev/peps/pep-0293/), it is certainly possible for the error handler to return a newpos outside the range start - end, meaning in most cases: a value >= end. There's a good reason for this: the codec

[issue36819] Crash during encoding using UTF-16/32 and custom error handler

Change by Marc-Andre Lemburg : -- components: +Unicode nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36819] Crash during encoding using UTF-16/32 and custom error handler

Change by Marc-Andre Lemburg : -- nosy: +doerwalter ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue45316] [C API] Functions not exported with PyAPI_FUNC()

Serhiy Storchaka added the comment: Agree. We should also review all recently added functions with PyAPI_FUNC(). If they are not intended to be public API, PyAPI_FUNC() should be removed and declarations moved. -- nosy: +serhiy.storchaka ___ Pyth

[issue36819] Crash during encoding using UTF-16/32 and custom error handler

Serhiy Storchaka added the comment: Restricting the returned position to be strictly larger than start would solve the problem with infinite loop and OOM. But this is a different issue. -- ___ Python tracker __

[issue36819] Crash during encoding using UTF-16/32 and custom error handler

Marc-Andre Lemburg added the comment: On 29.09.2021 10:41, Serhiy Storchaka wrote: > > Restricting the returned position to be strictly larger than start would > solve the problem with infinite loop and OOM. But this is a different issue. Yes, this would make sense, since having the codec pr

[issue39039] zlib.error with tarfile.open

Łukasz Langa added the comment: New changeset b6fe8572509b77d2002eaddf99d718e9b4835684 by Jack DeVries in branch 'main': bpo-39039: tarfile raises descriptive exception from zlib.error (GH-27766) https://github.com/python/cpython/commit/b6fe8572509b77d2002eaddf99d718e9b4835684 -- nos

[issue45308] multiprocessing default fork child process will not free object, which is inherited from parent process

eleven xiang added the comment: I am not asking for your help to use python. What I post here is to want to report a potential issue about multiprocessing module. This issue is the default start method fork will not free the object, but other methods works normally. When I change to use os.f

[issue40642] Cpython "pystate.h" subdirectory wrong

STINNER Victor added the comment: I mark this issue as a duplicate of bpo-39026. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure ___

[issue39026] pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure

STINNER Victor added the comment: I marked bpo-40642 as a duplicate of this issue. -- ___ Python tracker ___ ___ Python-bugs-list m

[issue45314] Using target python while cross-building

Frans added the comment: Update: I came to realize that the command 'python' is without './', so it will search using PATH for python. Which - on my system Opensuse TW - does not exist, since there we have 'python3'. So, I made a softlink python->python3. Alas, I noticed that when I made t

[issue39026] pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure

Change by STINNER Victor : -- pull_requests: +26982 pull_request: https://github.com/python/cpython/pull/28612 ___ Python tracker ___ __

[issue39026] Include/cpython/pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure

Change by STINNER Victor : -- title: pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure -> Include/cpython/pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure

[issue45308] multiprocessing default fork child process will not free object, which is inherited from parent process

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue39039] zlib.error with tarfile.open

Change by Łukasz Langa : -- pull_requests: +26983 pull_request: https://github.com/python/cpython/pull/28613 ___ Python tracker ___ _

[issue39026] Include/cpython/pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure

STINNER Victor added the comment: I'm not sure why Include/cpython/ is part of the compiler include directories. I am not sure why Include/ is *not* part of the compiler include directory. Anyway, it's hard to control how people build Python and there are always legit use cases where you fal

[issue39026] Include/cpython/pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure

STINNER Victor added the comment: I propose to only rename header files in Python 3.11. For Python 3.9 and 3.10, I suggest to modify Include/cpython/pystate.h by replacing: #include "cpython/initconfig.h" with: #include "initconfig.h" Like the PR 20181. -- _

[issue45314] Using target python while cross-building

Frans added the comment: Update 2: Using the python-3.8.12 sourceno problem! All functions well. So, 3.9 has some issues i guess ;) -- ___ Python tracker ___ ___

[issue39039] zlib.error with tarfile.open

Change by Łukasz Langa : -- pull_requests: +26984 pull_request: https://github.com/python/cpython/pull/28614 ___ Python tracker ___ _

[issue39717] Fix exception causes in tarfile module

Change by Łukasz Langa : -- nosy: +lukasz.langa nosy_count: 5.0 -> 6.0 pull_requests: +26985 pull_request: https://github.com/python/cpython/pull/28614 ___ Python tracker ___ __

[issue45316] [C API] Functions not exported with PyAPI_FUNC()

Change by Pablo Galindo Salgado : -- nosy: +Mark.Shannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue36521] Consider removing docstrings from co_consts in code objects

Mark Shannon added the comment: There is a clear disadvantage in moving the docstring from the function's code object to the enclosing code object: Docstrings are rarely looked at (relative to other operations on functions). Inner functions and comprehensions are created many times for the s

[issue24391] Better repr for threading objects

Serhiy Storchaka added the comment: New changeset eed32df5b6b989caf125d829301546db58b529dd by Serhiy Storchaka in branch 'main': bpo-24391: Better reprs for threading objects. (GH-20534) https://github.com/python/cpython/commit/eed32df5b6b989caf125d829301546db58b529dd -- __

[issue45316] [C API] Functions not exported with PyAPI_FUNC()

Mark Shannon added the comment: Regarding these three functions: void PyLineTable_InitAddressRange(const char *linetable, Py_ssize_t length, int firstlineno, PyCodeAddressRange *range); int PyLineTable_NextAddressRange(PyCodeAddressRange *range); int PyLineTable_PreviousAddressRange(PyCodeAdd

[issue39039] zlib.error with tarfile.open

Łukasz Langa added the comment: New changeset d6b69f21d8ec4af47a9c79f3f50d20be3d0875fc by Łukasz Langa in branch '3.10': [3.10] bpo-39039: tarfile raises descriptive exception from zlib.error (GH-27766) (GH-28613) https://github.com/python/cpython/commit/d6b69f21d8ec4af47a9c79f3f50d20be3d0875

[issue45229] Always use unittest for collecting tests in regrtests

Change by Serhiy Storchaka : -- pull_requests: +26986 pull_request: https://github.com/python/cpython/pull/28615 ___ Python tracker ___

[issue45291] Some instructions in the "Using Python on Unix platforms" document do no work on CentOS 7

Change by miss-islington : -- nosy: +miss-islington nosy_count: 2.0 -> 3.0 pull_requests: +26987 pull_request: https://github.com/python/cpython/pull/28616 ___ Python tracker _

[issue45291] Some instructions in the "Using Python on Unix platforms" document do no work on CentOS 7

Łukasz Langa added the comment: New changeset bc4cde40339dd372960f27401d8fdaa4dab0f469 by zhanpon in branch 'main': bpo-45291: Explicitly set --libdir=lib when configure OpenSSL (GH-28566) https://github.com/python/cpython/commit/bc4cde40339dd372960f27401d8fdaa4dab0f469 -- nosy: +luk

[issue39039] zlib.error with tarfile.open

Łukasz Langa added the comment: New changeset 7bff4d396f20451f20977be3ce23a879c6bc3e46 by Łukasz Langa in branch '3.9': [3.9] bpo-39039: tarfile raises descriptive exception from zlib.error (GH-27766) (GH-28614) https://github.com/python/cpython/commit/7bff4d396f20451f20977be3ce23a879c6bc3e46

[issue39039] zlib.error with tarfile.open

Łukasz Langa added the comment: Thanks for the fix, Jack! ✨ 🍰 ✨ Since the change translated `zlib.error` to `tarfile.ReadError` which already has to be handled by user code, it's strictly decreasing the surface of necessary exception handling. So, treating this as a bug fix, I backported th

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > There is a clear disadvantage in moving the docstring from the function's > code object to the enclosing code object: > > Docstrings are rarely looked at (relative to other operations on functions). > Inner functions and comprehensions are created many times f

[issue45317] Document the removal the usage of the C stack in Python to Python calls

New submission from Mark Shannon : Assuming that issue 45256 is implemented, we will need to document it. I'm opening a separate issue, so this doesn't get lost in the midst of 45256. We need to: Document the changes to gdb. Possibly at https://wiki.python.org/moin/DebuggingWithGdb, or in t

[issue45291] Some instructions in the "Using Python on Unix platforms" document do no work on CentOS 7

Łukasz Langa added the comment: New changeset 02fdd73a19464bafe9e5f98ecd17fd0a634c3f20 by Miss Islington (bot) in branch '3.10': bpo-45291: Explicitly set --libdir=lib when configure OpenSSL (GH-28566) (GH-28616) https://github.com/python/cpython/commit/02fdd73a19464bafe9e5f98ecd17fd0a634c3f2

[issue45317] Document the removal the usage of the C stack in Python to Python calls

Change by Mark Shannon : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue45291] Some instructions in the "Using Python on Unix platforms" document do no work on CentOS 7

Łukasz Langa added the comment: Thanks, Yiyang Zhan! ✨ 🍰 ✨ -- resolution: -> fixed stage: patch review -> resolved versions: +Python 3.11 ___ Python tracker ___ __

[issue45317] Document the removal the usage of the C stack in Python to Python calls

Change by Mark Shannon : -- assignee: docs@python -> Mark.Shannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue45317] Document the removal the usage of the C stack in Python to Python calls

Pablo Galindo Salgado added the comment: I will prepare a PR to also document the gdb helpers in the main docs. The wiki is insuficient. -- assignee: Mark.Shannon -> pablogsal ___ Python tracker ___

[issue45318] Python 3.10: cyclomatic complexity of match-case syntax

New submission from Boštjan Mejak : I am wondering about the cyclomatic complexity of using the new match-case syntax in Python 3.10, and later. What is the cyclomatic complexity difference (if any?) of a match-case code as opposed to code that uses the if-elif-else syntax? So my question is

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

New submission from Christian Heimes : While I was working on a patch to port wrapt to limited API and stable ABI, I noticed a possible regression in __annotations__ PyGetSetDef. It looks like C heap type subclasses no longer inherit the __annotations__ descriptor from a C heap type parent cl

[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

Pablo Galindo Salgado added the comment: If someone wants this issue to be solved in 3.10.0 it must be resolved ASAP. I am going to start freezing the release branch in one day or two to start testing the final candidate as much as possible so this issue has 24h at max to be merged into 3.10

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Change by Graham Dumpleton : -- nosy: +grahamd ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue45307] Removal of _PyImport_FindExtensionObject() in 3.10 limits custom extension module loaders

Change by Pablo Galindo Salgado : -- priority: release blocker -> stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

Pablo Galindo Salgado added the comment: This means that if anyone wants to pursue the 4% that is left the fix must be committed within 24 hours. -- priority: release blocker -> ___ Python tracker

[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

Pablo Galindo Salgado added the comment: I'm landing PR 28475 for now as it improves the situation from 7% to 4% slowdown and is contained enough. -- ___ Python tracker ___

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Pablo Galindo Salgado added the comment: Christian, could you bisect using your reproducer? -- ___ Python tracker ___ ___ Python-bu

[issue45320] Remove deprecated inspect functions

New submission from Hugo van Kemenade : inspect.getargspec was deprecated in docs since 3.0 (https://docs.python.org/3.0/library/inspect.html?highlight=getargspec#inspect.getargspec), raising a DeprecationWarning since 3.5 (bpo-20438, https://github.com/python/cpython/commit/3cfec2e2fcab9f391

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

Change by Pablo Galindo Salgado : -- pull_requests: +26988 pull_request: https://github.com/python/cpython/pull/28617 ___ Python tracker ___ ___

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Change by STINNER Victor : -- nosy: +petr.viktorin, vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Pablo Galindo Salgado added the comment: If you want a potential fix to be included in 3.10.0 it must be commited in the next 24/48 hours, otherwise it will need to wait for 3.10.1 -- nosy: -petr.viktorin, vstinner ___ Python tracker

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Christian Heimes added the comment: I'm bisecting now. -- nosy: +petr.viktorin, vstinner ___ Python tracker ___ ___ Python-bugs-lis

[issue44809] Changelog missing removal of StrEnum etc.

Pablo Galindo Salgado added the comment: The changelog says now: bpo-44559: [Enum] module reverted to 3.9; 3.10 changes pushed until 3.11 (https://docs.python.org/3.10/whatsnew/changelog.html#id9) Please, feel free to reopen if we are missing anything -- resolution: -> fixed stage:

[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

Ken Jin added the comment: > If someone wants this issue to be solved in 3.10.0 it must be resolved ASAP. neonene suggested that the tracing tests for pattern matching (added in 3.10b4/rc1) caused PGO to wrongly optimize the more uncommon tracing paths in ceval. I will verify their one-line

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue45316] [C API] Functions not exported with PyAPI_FUNC()

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue45295] Speed up classmethod calls via LOAD_METHOD

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue45320] Remove deprecated inspect functions

Change by Hugo van Kemenade : -- keywords: +patch pull_requests: +26989 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28618 ___ Python tracker __

[issue33582] formatargspec deprecated but does not emit DeprecationWarning.

Change by Hugo van Kemenade : -- nosy: +hugovk nosy_count: 6.0 -> 7.0 pull_requests: +26991 pull_request: https://github.com/python/cpython/pull/28618 ___ Python tracker ___ __

[issue20438] inspect: Deprecate getfullargspec?

Change by Hugo van Kemenade : -- nosy: +hugovk nosy_count: 11.0 -> 12.0 pull_requests: +26990 pull_request: https://github.com/python/cpython/pull/28618 ___ Python tracker ___

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Christian Heimes added the comment: The culprit is commit 2f2b69855d6524e15d12c15ddc0adce629e7de84 for bpo-43901: Lazy-create an empty annotations dict in all unannotated user classes and modules (GH-25623). -- ___ Python tracker

[issue45321] Module xml.parsers.expat.errors misses error code constants of libexpat >=2.0

New submission from sping : (This has been mention at https://bugs.python.org/issue44394#msg395642 before, but issue 44394 has been closed as fixed despite that part being forgotten, hence the dedicated ticket...) Module `xml.parsers.expat.errors` and its docs need 6 more error code entries

[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

neonene added the comment: I have another fix. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue44896] AttributeError in ast.unparse

Łukasz Langa added the comment: Sorry, I think we shouldn't be changing `ast.py` this way. To reiterate my review comment from the PR: I think we should just let this go and instead advertise that if you put new synthetic nodes in a tree, you have to either: - provide `lineno` and `col_offset

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

Change by miss-islington : -- pull_requests: +26992 pull_request: https://github.com/python/cpython/pull/28619 ___ Python tracker ___ __

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

Change by miss-islington : -- pull_requests: +26993 pull_request: https://github.com/python/cpython/pull/28620 ___ Python tracker ___ __

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

Pablo Galindo Salgado added the comment: New changeset 6c1154b9de29e1c9cd3d05f5289543e5cff73895 by Pablo Galindo Salgado in branch 'main': bpo-44394: Ensure libexpat is linked against libm (GH-28617) https://github.com/python/cpython/commit/6c1154b9de29e1c9cd3d05f5289543e5cff73895 -

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

Change by miss-islington : -- pull_requests: +26994 pull_request: https://github.com/python/cpython/pull/28621 ___ Python tracker ___ __

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Pablo Galindo Salgado added the comment: Ah, that is likely because type_getsets now gets directly an __annotations__ field. -- ___ Python tracker ___ ___

[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

Pablo Galindo Salgado added the comment: > I have another fix. If you have another fix, please create a PR ASAN and get it reviewed and merged by a core dev in the next 24 hours, otherwise it will need to wait until 3.10.1 -- ___ Python tracker <

[issue45220] Windows builds sometimes fail on Azure and GitHub Action: fatal error RC1116: RC terminating after preprocessor errors

Change by miss-islington : -- pull_requests: +26995 pull_request: https://github.com/python/cpython/pull/28622 ___ Python tracker ___ __

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

miss-islington added the comment: New changeset fafa213870193cf79557588ae8f9a4af570fd6e3 by Miss Islington (bot) in branch '3.9': bpo-44394: Ensure libexpat is linked against libm (GH-28617) https://github.com/python/cpython/commit/fafa213870193cf79557588ae8f9a4af570fd6e3 -- __

[issue45318] Python 3.10: cyclomatic complexity of match-case syntax

Mark Dickinson added the comment: @Boštjan Mejak: I think this question belongs on a discussion forum rather than in the Python bug tracker - as I understand it, there's no bug reported here, and no change to the Python core proposed. I'll close here. You might consider taking this to discuss

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

Change by Łukasz Langa : -- pull_requests: +26996 pull_request: https://github.com/python/cpython/pull/28624 ___ Python tracker ___ _

[issue45220] Windows builds sometimes fail on Azure and GitHub Action: fatal error RC1116: RC terminating after preprocessor errors

Łukasz Langa added the comment: New changeset 456d6d9fefac828c19fc1b562f6301f00965fe59 by Miss Islington (bot) in branch '3.8': bpo-45220: Avoid automatically selecting the Windows 11 SDK preview when building (GH-28393) (GH-28622) https://github.com/python/cpython/commit/456d6d9fefac828c19fc

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

Łukasz Langa added the comment: New changeset 412ae8ab10734b72384c969181919cc4eb154406 by Miss Islington (bot) in branch '3.10': [3.10] bpo-44394: Ensure libexpat is linked against libm (GH-28617) (GH-28621) https://github.com/python/cpython/commit/412ae8ab10734b72384c969181919cc4eb154406 --

[issue45211] Useful (expensive) information is discarded in getpath.c.

Eric Snow added the comment: Yeah, I was thinking along those lines too but hesitated. :) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker __

[issue45320] Remove deprecated inspect functions

Łukasz Langa added the comment: Have you done any checks how much external code is using the deprecated callables in the wild? I remember when the 3.5 deprecations started, a lot of libraries started emitting them because they stuck to `getargspec` which was Python 2 compatible. -- n

[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

Ken Jin added the comment: Sadly, I can't reproduce the speedups OP reported from disabling test_patma.TestTracing. It's not any faster than what we have with PR28475. (See attached pyperformance). I'm looking forward to their other fix :). Even if it comes in 3.10.1 that's still a huge win

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

Change by miss-islington : -- pull_requests: +26997 pull_request: https://github.com/python/cpython/pull/28627 ___ Python tracker ___ __

[issue45322] [X86_64]test_concurrent_futures fail

New submission from tongxiaoge : The error log is as follows: [ 1848s] 0:19:24 load avg: 22.28 [411/412/1] test_concurrent_futures failed (19 min 19 sec) -- running: test_capi (19 min 22 sec) [ 1848s] [ 1848s] Traceback: [ 1848s] Thread 0x7fb68ffab700 (most recent call first): [ 1848s] F

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

Łukasz Langa added the comment: New changeset 90004fca1cc3c6e3c9b2c3faae5cb1b7d7711648 by Miss Islington (bot) in branch '3.8': [3.8] bpo-44394: Ensure libexpat is linked against libm (GH-28617) (GH-28620) https://github.com/python/cpython/commit/90004fca1cc3c6e3c9b2c3faae5cb1b7d7711648

[issue45322] [X86_64]test_concurrent_futures fail

Christian Heimes added the comment: Please stop adding Victor and me to the noisy list. That's rather rude. A core dev or triager will pick up the ticket eventually and notify the relevant experts. -- ___ Python tracker

[issue45322] [X86_64]test_concurrent_futures fail

Change by Christian Heimes : -- nosy: -christian.heimes ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Christian Heimes added the comment: Larry, could you please take a look? Your commit is causing a regression for C subclasses of heap types when the parent class has an "__annotations__" descriptor. The child class no longer uses the descriptor of the parent class. -- nosy: +larry

[issue36819] Crash during encoding using UTF-16/32 and custom error handler

Walter Dörwald added the comment: The original specification (PEP 293) required that an error handler called for encoding *must* return a replacement string (not bytes). This returned string must then be encoded again. Only if this fails an exception must be raised. Returning bytes from the e

[issue45323] unexpected behavior on first match case _

New submission from Joël Bourgault : While testing the `match...case` construction, I get the following behavior with Docker image Python 3.10 rc2-slim: ```python >>> match "robert": ... case x if len(x) > 10: ... print("long nom") ... case [0, y]: ... print("point à x n

[issue45322] [X86_64]test_concurrent_futures fail

STINNER Victor added the comment: > File > "/home/abuild/rpmbuild/BUILD/Python-3.7.9/Lib/multiprocessing/queues.py", > line 224 in _feed Python 3.7 no longer accept bugfixes: I close the issue. You can open a new issue if you can reproduce the issue on Python 3.9 or newer: https://devguide.

[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

Pablo Galindo Salgado added the comment: > IMO, we should note in What's New that only for Windows, 3.10.0 has a slight > slowdown. I disagree. This is a regression/bug and we don't advertise "known bugs" in the what's new, the same for any other bugfix that has been delayed until 3.10.1 >

[issue45249] Update doctect SyntaxErrors for location range

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue45323] unexpected behavior on first match case _

Steven D'Aprano added the comment: If you are working in the interactive interpreter, you may be running into a conflict with the "magic" variable `_` which the interactive interpreter creates to hold the result of the last evaluated statement. So when you evaluate `x`, and that returns the

[issue45323] unexpected behavior on first match case _

Steven D'Aprano added the comment: It is a bit tricky to find the documentation for the magic single underscore, but it is here: https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers -- ___ Python tracker

[issue28206] signal.Signals not documented

Change by Hinrich Mahler : -- keywords: +patch pull_requests: +26998 pull_request: https://github.com/python/cpython/pull/28628 ___ Python tracker ___ _

  1   2   >