[issue46751] Windows-style path is not recognized under cygwin

Christoph Reiter added the comment: Afaik Cywin programs only work with native Windows paths if the paths happen to get directly passed to the OS APIs and not interpreted in any way before that. So I don't think this is a bug and expected behavior. Use "cygpath C:/path/to/script.py" to

[issue46677] TypedDict docs are incomplete

Change by Charlie Zhao : -- keywords: +patch pull_requests: +29498 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31349 ___ Python tracker ___

[issue45756] mock raises exception when using a spec with an attribute that raises exception on access

Change by hongweipeng : -- nosy: +hongweipeng nosy_count: 5.0 -> 6.0 pull_requests: +29497 pull_request: https://github.com/python/cpython/pull/31348 ___ Python tracker ___

[issue46733] pathlib.Path methods can raise NotImplementedError

Eryk Sun added the comment: WindowsPath.is_mount() should call ntpath.ismount(). This function needs a significant redesign, but it's fine to use it as long as it's documented that is_mount() is equivalent to os.path.ismount(). Since the owner() and group() methods return names instead of

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Change by Karthikeyan Singaravelan : -- nosy: +njs ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46754] Improve Python Language Reference based on [Köhl 2020]

New submission from Guido van Rossum : In https://arxiv.org/pdf/2109.03139.pdf ("M Köhl, An Executable Structural Operational Formal Semantics for Python, Master Thesis 2020 Saarland University) there are some observations on cases where the Language Reference (referred to as PLR) is

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

Eric Snow added the comment: New changeset 12360aa159c42c7798fd14225d271e6fd84db7eb by Eric Snow in branch 'main': bpo-46541: Discover the global strings. (gh-31346) https://github.com/python/cpython/commit/12360aa159c42c7798fd14225d271e6fd84db7eb --

[issue46728] Docstring of combinations_with_replacement for consistency

Dong-hee Na added the comment: New changeset 278fdd3e3a2492665b2c2888fd2f428f7f59a3f5 by DongGeon Lee in branch 'main': bpo-46728: fix docstring of combinations_with_replacement for consistency (GH-31293) https://github.com/python/cpython/commit/278fdd3e3a2492665b2c2888fd2f428f7f59a3f5

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

Change by Eric Snow : -- pull_requests: +29496 pull_request: https://github.com/python/cpython/pull/31346 ___ Python tracker ___

[issue46751] Windows-style path is not recognized under cygwin

Eryk Sun added the comment: MSYS2 has basically the same problem when the script is passed as a Windows path, except it uses "/c" for the "C:" drive instead of "/cygdrive/c". # python3 -VV Python 3.9.9 (main, Dec 28 2021, 11:05:23) [GCC 11.2.0] # echo $PWD /proc #

[issue46753] Statically allocate and initialize the empty tuple.

Change by Eric Snow : -- keywords: +patch pull_requests: +29495 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31345 ___ Python tracker

[issue20923] [doc] Explain ConfigParser 'valid section name' and .SECTCRE

Irit Katriel added the comment: It’s still open. Go for it. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue20923] [doc] Explain ConfigParser 'valid section name' and .SECTCRE

Vidhya added the comment: I am newbie to Python developer group and have the document source build and compiled successfully. Is this issue updated in the document. I would like to work on this if this is not closed. Please let me know. Thanks -- nosy: +vidhya.friend

[issue46753] Statically allocate and initialize the empty tuple.

Eric Snow added the comment: Also see bpo-45953. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46753] Statically allocate and initialize the empty tuple.

New submission from Eric Snow : Currently it is created dynamically from the tuple freelist. -- assignee: eric.snow components: Interpreter Core messages: 413268 nosy: eric.snow priority: normal severity: normal stage: needs patch status: open title: Statically allocate and initialize

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

Change by Eric Snow : -- pull_requests: +29494 pull_request: https://github.com/python/cpython/pull/31344 ___ Python tracker ___

[issue46436] Pass the -d/--directory command-line option to http.server.CGIHTTPRequestHandler

Éric Araujo added the comment: Thanks again! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46744] installers on ARM64 suggest wrong folders

conio added the comment: I understand. Though I think the naming scheme that includes platform identification is better, if *all* installers include the platform name unconditionally, including both amd64 and arm64, that's also an improvement. (So the names will be `Python311-32`,

[issue46749] Support cross compilation on macOS

Change by Ned Deily : -- components: +macOS -Cross-Build nosy: +ronaldoussoren ___ Python tracker ___ ___ Python-bugs-list mailing

[issue46749] Support cross compilation on macOS

Ned Deily added the comment: We don't currently support cross-building a single macOS architecture on another, i.e. building an x86_64 only build on an Apple Silicon Mac. However, we do support building a multi-architecture build on either on current releases of Python 3.9 and 3.10, with

[issue46751] Windows-style path is not recognized under cygwin

Mike Kaganski added the comment: > As for 3.9: it's not available through the 64 bit installer (at least, I > don't see it there). I'll look and see what's involved in installing it. I don't remember if I did something special to install it; however, just maybe you need to install python39

[issue46566] Support -3.11-arm64 in py.exe launcher

Change by conio : -- nosy: +conio ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46733] pathlib.Path methods can raise NotImplementedError

Barney Gale added the comment: Thanks very much Alex. I've added some PRs: PR 31338 addresses owner(), group() and is_mount(). It moves those methods to PosixPath, and adds stubs in WindowsPath that raise deprecation warnings. I agree with your analysis that, for static typing purposes,

[issue46744] installers on ARM64 suggest wrong folders

Steve Dower added the comment: Thanks for the additional info! I agree with the design you propose. It would be much easier to make the ARM64 install use the tagged directory though (C:\Program Files\Python 3.11-arm64). I'd rather not get into the business of detecting platforms from the

[issue46751] Windows-style path is not recognized under cygwin

Steve Dower added the comment: Does Cygwin not use : as a path list separator? (What would normally be ; on Windows.) Perhaps the CPython build needs to be patched specially here to handle different separator character. -- ___ Python tracker

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Change by Guido van Rossum : -- keywords: +patch pull_requests: +29493 pull_request: https://github.com/python/cpython/pull/31270 ___ Python tracker ___

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

New submission from Guido van Rossum : After some conversations with Yury, and encouraged by the SC's approval of PEP 654, I am proposing to add a new class, asyncio.TaskGroup, which introduces structured concurrency similar to nurseries in Trio. I started with EdgeDb's TaskGroup

[issue46751] Windows-style path is not recognized under cygwin

Eric V. Smith added the comment: >:) Citing myself: >> Trying this *bash* command line: Oops, sorry for missing that. As for 3.9: it's not available through the 64 bit installer (at least, I don't see it there). I'll look and see what's involved in installing it. Are you running the 32-

[issue46436] Pass the -d/--directory command-line option to http.server.CGIHTTPRequestHandler

Mariatta added the comment: New changeset b27195332e91e932501f16cf9877761b218a9c99 by Miss Islington (bot) in branch '3.10': bpo-46436: Fix command-line option -d/--directory in module http.server (GH-30701) https://github.com/python/cpython/commit/b27195332e91e932501f16cf9877761b218a9c99

[issue46436] Pass the -d/--directory command-line option to http.server.CGIHTTPRequestHandler

Mariatta added the comment: New changeset 502ad3930ee8fcf76026edfc06a33621363cebea by Miss Islington (bot) in branch '3.9': bpo-46436: Fix command-line option -d/--directory in module http.server (GH-30701) https://github.com/python/cpython/commit/502ad3930ee8fcf76026edfc06a33621363cebea

[issue46751] Windows-style path is not recognized under cygwin

Mike Kaganski added the comment: Thanks for looking at this! > Are you running from bash (or another cygwin shell), or from cmd.exe, or > something else? :) Citing myself: > Trying this *bash* command line: > To my knowledge, cygwin's installer doesn't have a 3.9 available. It does:

[issue46733] pathlib.Path methods can raise NotImplementedError

Change by Barney Gale : -- pull_requests: +29491 pull_request: https://github.com/python/cpython/pull/31340 ___ Python tracker ___

[issue46733] pathlib.Path methods can raise NotImplementedError

Change by Barney Gale : -- pull_requests: +29492 pull_request: https://github.com/python/cpython/pull/31341 ___ Python tracker ___

[issue46733] pathlib.Path methods can raise NotImplementedError

Change by Barney Gale : -- pull_requests: +29490 pull_request: https://github.com/python/cpython/pull/31339 ___ Python tracker ___

[issue46733] pathlib.Path methods can raise NotImplementedError

Change by Barney Gale : -- keywords: +patch pull_requests: +29489 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31338 ___ Python tracker ___

[issue38619] [Doc] UUID.hex is lowercase

miss-islington added the comment: New changeset 1953f03174c18f315aca883babc3819828f868d8 by Miss Islington (bot) in branch '3.9': bpo-38619: Update the documentation for UUID.hex (GH-29830) https://github.com/python/cpython/commit/1953f03174c18f315aca883babc3819828f868d8 --

[issue38619] [Doc] UUID.hex is lowercase

miss-islington added the comment: New changeset 828253227efe16f0e759df36bbb2ca49083223c8 by Miss Islington (bot) in branch '3.10': bpo-38619: Update the documentation for UUID.hex (GH-29830) https://github.com/python/cpython/commit/828253227efe16f0e759df36bbb2ca49083223c8 --

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

Pablo Galindo Salgado added the comment: Cool! Be aware that using it outside codeop is currently unsupported: https://github.com/python/cpython/blob/5d53cf30f9cb3758849e859db5d4602cb7c521f7/Lib/codeop.py#L43-L47 So have in mind that the flag, mechanism and semantics can change without

[issue46750] some code paths in ssl and _socket still import idna unconditionally

Shivaram Lingamneni added the comment: (Looks like it was 15 milliseconds when measuring inside `python -i`; I'm not sure what the root cause of the difference is, but clearly the 5 millisecond measurement from regular `python` is more accurate.) --

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

Mateusz Loskot added the comment: Possibly, the new partial-input mode of the parser (https://bugs.python.org/issue46521#msg412832) will improve this issue in 3.11. I'm going to play with it soon and I will report back. -- ___ Python tracker

[issue46751] Windows-style path is not recognized under cygwin

Eric V. Smith added the comment: Are you running from bash (or another cygwin shell), or from cmd.exe, or something else? How did you install the version of python you're executing in the examples you provided? To my knowledge, cygwin's installer doesn't have a 3.9 available. I don't see

[issue38619] [Doc] UUID.hex is lowercase

Mariatta added the comment: Thanks. I do think it is helpful to state that it is lowercase. I have merged the PR, and will backport to 3.10 and 3.9. Thanks. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10, Python 3.11

[issue38619] [Doc] UUID.hex is lowercase

Change by miss-islington : -- nosy: +miss-islington nosy_count: 7.0 -> 8.0 pull_requests: +29487 pull_request: https://github.com/python/cpython/pull/31334 ___ Python tracker

[issue38619] [Doc] UUID.hex is lowercase

Mariatta added the comment: New changeset 5d53cf30f9cb3758849e859db5d4602cb7c521f7 by 180909 in branch 'main': bpo-38619: Update the documentation for UUID.hex (GH-29830) https://github.com/python/cpython/commit/5d53cf30f9cb3758849e859db5d4602cb7c521f7 -- nosy: +Mariatta

[issue38619] [Doc] UUID.hex is lowercase

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

[issue46751] Windows-style path is not recognized under cygwin

New submission from Mike Kaganski : Using cyqwin 3.3.4-2, and python3: Python 3.9.10 (main, Jan 20 2022, 21:37:52) [GCC 11.2.0] on cygwin Trying this bash command line: > python3 C:/path/to/script.py results in this error: "python3: can't open file

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

Eric Snow added the comment: With core code sorted out, stdlib and 3rd party extension modules are left to sort out. I see the following possibilities: 1. leave `_Py_IDENTIFIER()` alone (it is already disallowed in core code) 2. change `_Py_IDENTIFIER()` to create static string objects

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

Change by Eric Snow : -- Removed message: https://bugs.python.org/msg413241 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue46750] some code paths in ssl and _socket still import idna unconditionally

Shivaram Lingamneni added the comment: Sorry, I should have been more clear: I am including the initial costs of importing stringprep and unicodedata. On my system: $ python3 -c "import time; start = time.time(); r = 'a'.encode('idna'); elapsed = time.time() - start; print(elapsed)"

[issue46739] dataclasses __eq__ isn't logical

Craig Coleman added the comment: >From https://docs.python.org/3/reference/datamodel.html#object.__hash__ User-defined classes have __eq__() and __hash__() methods by default; with them, all objects compare unequal (except with themselves) and x.__hash__() returns an appropriate value such

[issue46739] dataclasses __eq__ isn't logical

Craig Coleman added the comment: Seems I learned a python lesson today. I've put myself back in python school and done some reading on a) the code behind dataclasses, b) PEP 557 and c) the doc'n for __eq__. After all the reading I've realised this I'd been making some assumptions about how

[issue46739] dataclasses __eq__ isn't logical

Change by Dennis Sweeney : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue46750] some code paths in ssl and _socket still import idna unconditionally

Christian Heimes added the comment: It's 100 times faster. The initial import takes about 150 μsec (0.15msec) and it's a one time cost. IDNA encoding of a typical hostname is about 70nsec. A DNS lookup is three magnitudes slower. -- ___ Python

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

Eric Snow added the comment: With core code sorted out, stdlib and 3rd party extension modules are left to sort out. I see the following possibilities: * leave `_Py_IDENTIFIER()` alone (it is already disallowed in core code) * change `_Py_IDENTIFIER()` to create static string objects (then

[issue46474] Inefficient regular expression complexity in EntryPoint.pattern

Łukasz Langa added the comment: New changeset 8a84aef0123bd8c13cf81fbc3b5f6d45f96c2656 by Jason R. Coombs in branch '3.8': [3.8] bpo-46474: Avoid REDoS in EntryPoint.pattern (sync with importlib_metadata 4.10.1) (GH-30803). (#30829)

[issue46748] Python.h includes stdbool.h

Petr Viktorin added the comment: It is in C99, but in an optional header. IMO, including the header in the internals is perfectly OK, but opting everyone else in isn't very nice. i.e. it would probably be OK to use `_Bool`, the actual C99 keyword that `bool` is defined as. But that's ugly

[issue46743] Enable usage of object.__orig_class__ in __init__

Guido van Rossum added the comment: Yeah, that should erase the type, not have special semantics. -- ___ Python tracker ___ ___

[issue46750] some code paths in ssl and _socket still import idna unconditionally

Shivaram Lingamneni added the comment: Thanks for the prompt response. As evidence that this was of concern to the development team in the past, here's an issue where the unnecessary import of idna was treated as a regression: https://bugs.python.org/issue22127 The discussion there also

[issue46743] Enable usage of object.__orig_class__ in __init__

Gobot1234 added the comment: > Which classes? Every class that inherits from Generic? That would be > problematic -- we don't want the addition of typing information to change the > behavior of a construct (or at least as little as possible). The class itself would remain unchanged, the

[issue46748] Python.h includes stdbool.h

Eric Snow added the comment: On Mon, Feb 14, 2022 at 2:28 AM Petr Viktorin wrote: > Eric, is this necessary? Would an old-school `int` do? > Or should we say it's 2022 already and everyone needs to use stdbool.hfore > bools? I started using ``bool`` (stdbool.h) when I saw it specified in

[issue46679] test.support.wait_process ignores timeout argument

Change by Nikita Sobolev : -- nosy: +sobolevn nosy_count: 1.0 -> 2.0 pull_requests: +29486 pull_request: https://github.com/python/cpython/pull/31274 ___ Python tracker ___

[issue46747] bisect.bisect/insort don't document key parameter

Dennis Sweeney added the comment: Thanks for the report, Stefan! Thanks for the PR, Zackery! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue46747] bisect.bisect/insort don't document key parameter

Dennis Sweeney added the comment: New changeset 841c77d802e9ee8845fa3152700474021efe03fd by Dennis Sweeney in branch '3.10': [3.10] bpo-46747: Add missing key parameters in the bisect docs (GH-31323) (GH-31329)

[issue46743] Enable usage of object.__orig_class__ in __init__

Guido van Rossum added the comment: > On the general class instanciation point would there be anything wrong with > just adding a big red warning saying (on the non-existent) docs for these > classes that they don't follow normal class initization or is this too > insignificant of an issue

[issue46750] some code paths in ssl and _socket still import idna unconditionally

Christian Heimes added the comment: Please provide benchmarks and data for your claim that encodings.idna is a performance bottleneck. encodings.idna is a simple, short module without state. On my system it takes about 0.15 msec to import the module. When unicodedata and stringprep aren't

[issue46747] bisect.bisect/insort don't document key parameter

Change by Dennis Sweeney : -- pull_requests: +29485 pull_request: https://github.com/python/cpython/pull/31329 ___ Python tracker ___

[issue46747] bisect.bisect/insort don't document key parameter

Dennis Sweeney added the comment: New changeset 96084f4256d2d523b0a4d7d900322b032326e3ed by Zackery Spytz in branch 'main': bpo-46747: Add missing key parameters in the bisect docs (GH-31323) https://github.com/python/cpython/commit/96084f4256d2d523b0a4d7d900322b032326e3ed -- nosy:

[issue46750] some code paths in ssl and _socket still import idna unconditionally

Change by Shivaram Lingamneni : -- keywords: +patch pull_requests: +29484 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31328 ___ Python tracker

[issue46750] some code paths in ssl and _socket still import idna unconditionally

New submission from Shivaram Lingamneni : Importing the idna encoding has a significant time and memory cost. Therefore, the standard library tries to avoid importing it when it's not needed (i.e. when the domain name is already pure ASCII), e.g. in Lib/http/client.py and

[issue46586] In documentation contents enum.property erroneously links to built-in property

Meer Suri added the comment: https://docs.python.org/3.11/library/io.html?highlight=io#text-i-o - The easiest way to create a text stream is with open(), optionally specifying an encoding: https://docs.python.org/3.11/library/io.html?highlight=io#binary-i-o - The easiest way to create a

[issue46741] Docstring for asyncio.protocols.BufferedProtocol appears out of date

Alex Waygood added the comment: Thanks, Andrew! I've submitted a patch. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue46741] Docstring for asyncio.protocols.BufferedProtocol appears out of date

Change by Alex Waygood : -- keywords: +patch pull_requests: +29483 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31327 ___ Python tracker ___

[issue46724] Odd Bytecode Generation in 3.10

Change by Mark Shannon : -- pull_requests: +29482 pull_request: https://github.com/python/cpython/pull/31326 ___ Python tracker ___

[issue46622] Support decorating a coroutine with functools.cached_property

Andrew Svetlov added the comment: >From my point of view, both sync and async functions can be cached. Sync and async iterators/generators are other beasts: they don't return a value but generate a series of items. The series can be long and memory-consuming, I doubt if it should be cached

[issue46622] Support decorating a coroutine with functools.cached_property

Serhiy Storchaka added the comment: Note that there is a similar issue with cached generators. >>> from functools import * >>> @lru_cache() ... def g(): ... yield 1 ... >>> list(g()) [1] >>> list(g()) [] I am not sure that it is safe to detect awaitables and iterables in caching

[issue46749] Support cross compilation on macOS

Change by autoantwort : -- components: +Cross-Build -Build nosy: +Alex.Willmer ___ Python tracker ___ ___ Python-bugs-list mailing

[issue46749] Support cross compilation on macOS

New submission from autoantwort : Currently you get the following output: ``` ➜ debug git:(main) ✗ ../configure --host=x86_64-apple-darwin --build=arm64-apple-darwin --with-build-python=./python3.11 checking for git... found checking build system type... aarch64-apple-darwin checking host

[issue46622] Support decorating a coroutine with functools.cached_property

Andrew Svetlov added the comment: Agree. Let's start from async functions support by `functools.lru_cache`. If we will have an agreement that cached_property is an important use-case we can return to this issue. I have a feeling that async lru_cache is much more important.

[issue46072] Unify handling of stats in the CPython VM

Change by Mark Shannon : -- pull_requests: +29481 pull_request: https://github.com/python/cpython/pull/31324 ___ Python tracker ___

[issue46622] Support decorating a coroutine with functools.cached_property

Tzu-ping Chung added the comment: I agree that `print(await a.hello)` does look awkward, although I know some would disagree. (Context: I submitted this BPO after a colleague of mine at $WORK pointed out the behavioural difference between `functools` and `cached_property to me.) Personally

[issue46743] Enable usage of object.__orig_class__ in __init__

Gobot1234 added the comment: On the general class instanciation point would there be anything wrong with just adding a big red warning saying (on the non-existent) docs for these classes that they don't follow normal class initization or is this too insignificant of an issue to bother? > I

[issue46748] Python.h includes stdbool.h

Petr Viktorin added the comment: Yes, stdbool.h is essentially a backport of C++'s bool type to C. -- ___ Python tracker ___ ___

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Eryk Sun added the comment: > 4) use Job objects to group Windows processes for termination I think a separate issue should be created for this enhancement. _winapi wrappers would be needed for CreateJobObjectW(), SetInformationJobObject(), AssignProcessToJobObject(), TerminatejobObject(),

[issue46741] Docstring for asyncio.protocols.BufferedProtocol appears out of date

Andrew Svetlov added the comment: Alex, you are right. BufferedProtocol is considered stable since 3.8 A pull request with docstring fix is welcome. -- ___ Python tracker ___

[issue46745] Typo in new PositionsIterator

Change by Alex Waygood : -- keywords: +patch stage: -> patch review type: -> behavior ___ Python tracker ___ ___ Python-bugs-list

[issue46747] bisect.bisect/insort don't document key parameter

Change by Alex Waygood : -- nosy: +rhettinger type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46748] Python.h includes stdbool.h

Serhiy Storchaka added the comment: Is it compatible with C++? -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue46748] Python.h includes stdbool.h

New submission from Petr Viktorin : In main, cpython/pystate.h newly includes stdbool.h, providing a definition for `bool` that might be incompatible with other software. See here: https://github.com/cmusphinx/sphinxbase/pull/90 Eric, is this necessary? Would an old-school `int` do? Or

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Eryk Sun added the comment: > I fear the potential 3rd-party breakage alone should bump > this to its own issue. The change to the DWORD converter in _winapi should only be in 3.11+. If this causes problems for other projects, they're probably depending on undefined behavior in the standard

[issue46747] bisect.bisect/insort don't document key parameter

Zackery Spytz added the comment: Thank you for the report. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46747] bisect.bisect/insort don't document key parameter

Change by Zackery Spytz : -- keywords: +patch nosy: +ZackerySpytz nosy_count: 2.0 -> 3.0 pull_requests: +29480 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31323 ___ Python tracker