[issue2771] Test issue

Ezio Melotti added the comment: So long, and thanks for all the bugs. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue47260] os.closerange() can be no-op in a seccomp sandbox

miss-islington added the comment: New changeset 89697f7374ea947ebe8e36131e2d3e21fff6fa1d by Miss Islington (bot) in branch '3.10': bpo-47260: Fix os.closerange() potentially being a no-op in a seccomp sandbox (GH-32418)

[issue47259] Clarify SortingHOWTO regarding locale aware string sorting

Change by Raymond Hettinger : -- title: string sorting often incorrect -> Clarify SortingHOWTO regarding locale aware string sorting versions: +Python 3.10, Python 3.11 ___ Python tracker

[issue47259] string sorting often incorrect

Raymond Hettinger added the comment: I don't think splashing this everywhere else in the docs would be helpful. Tools like list.sort, sorted, min, max, nlargest, nsmallest use whatever sort order is provided by the underlying object whether it be a string, tuple, float, or int. The

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Gregory P. Smith added the comment: Good catch. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Change by miss-islington : -- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +30445 pull_request: https://github.com/python/cpython/pull/32420 ___ Python tracker

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Gregory P. Smith added the comment: New changeset 1c8b3b5d66a629258f1db16939b996264a8b9c37 by Alexey Izbyshev in branch 'main': bpo-47260: Fix os.closerange() potentially being a no-op in a seccomp sandbox (GH-32418)

[issue5901] missing meta-info in documentation pdf

Ned Deily added the comment: The problem seems to have been fixed again somewhere in the past. -- nosy: +ned.deily resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.5, Python 3.6

[issue47087] Implement PEP 655 (Required/NotRequired)

Change by Jelle Zijlstra : -- keywords: +patch pull_requests: +30444 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32419 ___ Python tracker

[issue35962] [doc] Slight error in words in [ 2.4.1. String and Bytes literals ]

Change by Irit Katriel : -- keywords: +easy priority: normal -> low title: Slight error in words in [ 2.4.1. String and Bytes literals ] -> [doc] Slight error in words in [ 2.4.1. String and Bytes literals ] versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.7,

[issue44213] LIST_TO_TUPLE placed below the sentence "all of the following use their opcodes" in dis library documentaiton.

Irit Katriel added the comment: The "all of the following.. " sentence has been removed in 3.11. -- nosy: +iritkatriel resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue47255] Many broken :meth: roles in the docs

Ken Jin added the comment: It's 3.10 only. Presumably our sphinx version changed then and something broke. In 3.9 and earlier the links are all fine. See https://bugs.python.org/issue42182 for a similar issue I raised ages ago. -- nosy: +kj ___

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Change by Alexey Izbyshev : -- keywords: +patch stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Alexey Izbyshev added the comment: > It's been years now and that hasn't happened, even with more recent flag > additions. I think it's safe to say it won't, and such a fallback upon error > won't put us back into a bogus pre-close_range situation where we're > needlessly close()ing a bunch

[issue47261] RFC: Clarify usage of macros for PySequence_Fast within the Limited C API

Change by Rohit Goswami : -- title: RFC: Clarify Limited API macros for PySequence_Fast -> RFC: Clarify usage of macros for PySequence_Fast within the Limited C API ___ Python tracker

[issue47261] RFC: Clarify Limited API macros for PySequence_Fast

Rohit Goswami added the comment: Perhaps to be clear, there are two possibilities: 1. `PySequence_Fast` should be removed from the Limited API 2. All macros used with `PySequence_Fast` are valid for use in the context of the Limited API In either case the documentation should need to be

[issue47261] RFC: Clarify Limited API macros for PySequence_Fast

Change by Rohit Goswami : -- assignee: -> docs@python components: +C API, Documentation nosy: +docs@python ___ Python tracker ___

[issue47261] RFC: Clarify Limited API macros for PySequence_Fast

New submission from Rohit Goswami : The `current documentation`_ of the Python-C API mentions that ``PySequence_Fast`` is part of the limited API. However, this may be a typo as all the functions interacting with a ``PySequence_Fast`` object are macros, e.g. `PySequence_Fast_GET_SIZE`,

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Change by Alexey Izbyshev : -- keywords: +patch pull_requests: +30443 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32418 ___ Python tracker ___

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Kyle Evans added the comment: Sure, sounds good to me. The original theory (IIRC, I've slept many times since then :-)) was that we already know first/last are valid and there are no other defined errors, so 'other errors' must be because close_range has started percolating up something

[issue40421] [C API] Add public getter functions for the internal PyFrameObject structure

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

[issue39187] urllib.robotparser does not respect the longest match for the rule

matele secretaire added the comment: Thank you -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47260] os.closerange() can be no-op in a seccomp sandbox

New submission from Alexey Izbyshev : After #40422 _Py_closerange() assumes that close_range() closes all file descriptors even if it returns an error (other than ENOSYS): if (close_range(first, last, 0) == 0 || errno != ENOSYS) { /* Any errors encountered while closing file

[issue47168] Improvements for stable ABI definition files

Petr Viktorin added the comment: Thinking more about Doc/data/stable_abi.dat, I don't think the rename is worth it. The file is not meant to be used/edited by humans. If someone needs the data for something other than running the Sphinx extension, let me know. We should provide a proper data

[issue47245] potential undefined behavior with subprocess using vfork() on Linux?

Марк Коренберг added the comment: I have studied assembler output of _posixsubprocess.o compilation. Yes, everything seems safe. So, I'm closing the bug. -- resolution: -> works for me stage: test needed -> resolved status: open -> closed ___

[issue47168] Improvements for stable ABI definition files

Change by Petr Viktorin : -- pull_requests: +30441 pull_request: https://github.com/python/cpython/pull/32415 ___ Python tracker ___

[issue47138] Pin Jinja2 to fix docs build

Łukasz Langa added the comment: New changeset d35af52caae844cb4ea0aff06fa3fc5328708af1 by m-aciek in branch '3.8': [3.8] bpo-47138: Fix documentation build by pinning Jinja version to 3.0.3 (GH-32109) https://github.com/python/cpython/commit/d35af52caae844cb4ea0aff06fa3fc5328708af1

[issue47234] PEP-484 "numeric tower" approach makes it hard/impossible to specify contracts in documentation

Thomas Fischbacher added the comment: Re AlexWaygood: If these PEP-484 related things were so obvious that they would admit a compact description of the problem in 2-3 lines, these issues would likely have been identified much earlier. We would not be seeing them now, given that Python by

[issue47169] Stable ABI: Some optional (#ifdef'd) functions aren't handled correctly

Change by Petr Viktorin : -- pull_requests: +30440 pull_request: https://github.com/python/cpython/pull/32414 ___ Python tracker ___

[issue47234] PEP-484 "numeric tower" approach makes it hard/impossible to specify contracts in documentation

Alex Waygood added the comment: Please try to make your messages more concise. -- ___ Python tracker ___ ___ Python-bugs-list

[issue47259] string sorting often incorrect

Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23312] google thinks the docs are mobile unfriendly

Change by Petr Viktorin : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ ___

[issue23312] google thinks the docs are mobile unfriendly

Petr Viktorin added the comment: This has been solved by the new theme. The Goolgle report linked above shows “Passed” and “96” (out of 100). It does show a few opportunities to improve, but many seem to indirectly complain that the page is big. I'm closing the issue. -- nosy:

[issue47229] IDLE UI crashes on Chromebook Linux/Bullseye

Doug Bates added the comment: 'cc' Terry to say thank you. Just fyi I regressed my Chromebook to Debian/Buster form Bullseye, as IDLE and Thonny had previously worked seamlessly but now it doesn't work on Bullseye either -> so Google must have broken something along the way upgrading

[issue47046] Add `f_state` attribute to FrameObjects.

Mark Shannon added the comment: Don't you need to know if a "call" event is a call or the resumption of a generator? -- ___ Python tracker ___

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Steve Dower added the comment: > __assume(0) should be replaced with other function, inside the eval > switch-case or in the inlined paths of callees. This is critical with PGO. Out of interest, have you done other experiments confirming this? The reference linked is talking about compiler

[issue47103] Copy pgort140.dll when building for PGO

Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue47245] potential undefined behavior with subprocess using vfork() on Linux?

Alexey Izbyshev added the comment: > 3. We have to fix error-path in order not to change heap state (contents and > allocations), possibly do not touch locks. During vfork() child execution - > the only parent THREAD (not the process) is blocked. For example, it's not > allowed to touch

[issue35823] Use vfork() in subprocess on Linux

Марк Коренберг added the comment: Yes, you are almost right. Error-path is not so clear (it is discussed in another issue), but in general, yes, my previous comment is wrong. So, finally, there are no bugs around the stack at all. -- ___ Python

[issue47245] potential undefined behavior with subprocess using vfork() on Linux?

Марк Коренберг added the comment: So, finally: 1. Regarding vfork() and stack - everything is nice. No bugs because libc has nasty hacks for stack restoration. 2. Having the ability to turn off vfork using environment variables is NICE. At least, one can easily compare the performance. 3.

[issue40421] [C API] Add public getter functions for the internal PyFrameObject structure

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

[issue47259] string sorting often incorrect

Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47257] add methods to get first and last elements of a range

paul rubin added the comment: Oh nice, I didn't realize you could do that. len(range) and bool(range) (to test for empty) also work. Ok I guess this enhancement is not needed. I will close ticket, hope that is procedurally correct, otherwise feel free to fix. Thanks. --

[issue47259] string sorting often incorrect

New submission from Pierre Ossman : There is a big gotcha in Python that is easily overlooked and should at the very least be more prominently pointed out in the documentation. Sorting strings will produce results that is very confusing for humans. I happens to work for ASCII, but will

[issue40280] Consider supporting emscripten/webassembly as a build target

Change by Christian Heimes : -- pull_requests: +30438 pull_request: https://github.com/python/cpython/pull/32412 ___ Python tracker ___

[issue47257] add methods to get first and last elements of a range

Mark Dickinson added the comment: > but it's messy and potentially tricky to get the actual first and last values > of the range Doesn't simple indexing already provide what you need here? >>> range(1, 5, 2)[0] # first element of range 1 >>> range(1, 5, 2)[-1] # last element of range 3

[issue35823] Use vfork() in subprocess on Linux

Alexey Izbyshev added the comment: The preceding comment is wrong, see discussion in #47245 and https://bugzilla.kernel.org/show_bug.cgi?id=215813#c14 for explanation of why that bug report is irrelevant for CPython. -- ___ Python tracker

[issue47121] math.isfinite() can raise exception when called on a number

Thomas Fischbacher added the comment: Tim, the problem may well be simply due to the documentation of math.isfinite() being off here. This is what we currently have: https://docs.python.org/3/library/math.html#math.isfinite === math.isfinite(x) Return True if x is neither an infinity nor a

[issue46263] FreeBSD buildbots cannot compile Python

Change by Kubilay Kocak : -- nosy: +koobs ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47258] Python 3.10 hang at exit in drop_gil() (due to resource warning at exit?)

New submission from Richard Purdie : We had a python hang at shutdown. The gdb python backtrace and C backtraces are below. It is hung in the COND_WAIT(gil->switch_cond, gil->switch_mutex) call in drop_gil(). Py_FinalizeEx -> handle_system_exit() -> PyGC_Collect -> handle_weakrefs ->

[issue47234] PEP-484 "numeric tower" approach makes it hard/impossible to specify contracts in documentation

Thomas Fischbacher added the comment: This is not a partial duplicate of https://bugs.python.org/issue47121 about math.isfinite(). The problem there is about a specific function on which the documentation may be off - I'll comment separately on that. The problem here is: There is a

[issue43944] Processes in Python 3.9 exiting with code 1 when It's created inside a ThreadPoolExecutor

Thomas Grainger added the comment: the problem is multiprocessing/process is calling threading._shutdown which tries to join its own thread, because concurrent.futures.thread._threads_queues contains the main thread in the subprocess File

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Marco Barisione added the comment: Actually, sorry I realise I can pass `include_extras` to `get_type_hints`. Still, it would be nicer not to have to do that. -- ___ Python tracker

[issue47245] potential undefined behavior with subprocess using vfork() on Linux?

Alexey Izbyshev added the comment: > As for glibc specifics, I'm mostly thinking of the calls we do in the child. > According to the "Standard Description (POSIX.1)" calls to anything other > than `_exit()` or `exec*()` are not allowed. But the longer "Linux > Description" in that vfork(2)

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Marco Barisione added the comment: This is particularly annoying if you are using `Annotated` with a dataclass. For instance: ``` from __future__ import annotations import dataclasses from typing import Annotated, get_type_hints @dataclasses.dataclass class C: v: Annotated[int, "foo"]

[issue47257] add methods to get first and last elements of a range

New submission from paul rubin : Inspired by a question on comp.lang.python about how to deal with an int set composed of integers and ranges. Range objects like range(1,5,2) contain start, stop, and step values, but it's messy and potentially tricky to get the actual first and last values

[issue47248] Possible slowdown of regex searching in 3.11

Ma Lin added the comment: > Possibly related to the new atomic grouping support from GH-31982? It seems not likely. I will do some benchmarks for this issue, more information (version/platform) is welcome. -- ___ Python tracker

[issue47256] re: limit the maximum capturing group to 1, 073, 741, 823, reduce sizeof(match_context).

Change by Ma Lin : -- keywords: +patch pull_requests: +30437 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32411 ___ Python tracker ___

[issue47256] re: limit the maximum capturing group to 1, 073, 741, 823, reduce sizeof(match_context).

New submission from Ma Lin : These changes reduce sizeof(match_context): - 32-bit build: 36 bytes, no change. - 64-bit build: 72 bytes -> 56 bytes. sre uses stack and `match_context` struct to simulate recursive call, smaller struct brings: - deeper recursive call - less memory consume

[issue47248] Possible slowdown of regex searching in 3.11

Dennis Sweeney added the comment: Possibly related to the new atomic grouping support from GH-31982? -- nosy: +Dennis Sweeney, serhiy.storchaka ___ Python tracker ___