[issue46016] fcntl module add F_DUP2FD_CLOEXEC

STINNER Victor added the comment: New changeset da3cf4304f6dd530533bbd2c0913b674cd803744 by Victor Stinner in branch 'main': bpo-46016: GHA Doc job now also runs "make check" (GH-30009) https://github.com/python/cpython/commit/da3cf4304f6dd530533b

[issue46034] Patch-adding __init__ in a class takes no effect when called from a subinterpreter

STINNER Victor added the comment: I mark this issue as a duplicate of bpo-46006. It's not exactly the same issue, but the root cause is the same: in some functions, Python use fast pointer comparisons when two strings are interned, but this now fails if two interned strings belong t

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: I marked bpo-46034 as a duplicate: setting a class "__init__" attribute doesn't update properly its tp_init slot. update_slot() of Objects/typeobject.c only uses a fast pointer comparison since both strings are interned, but the test f

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: Attachd cmp_interned_strings.patch fix _PyUnicode_EqualToASCIIId() and update_slot() for subinterpreters. I will create a PR once we agree if it's required to support subinterpreters there, and if there is no better (faster) option. For update_slot()

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

Change by STINNER Victor : -- keywords: +3.10regression nosy: +pablogsal priority: normal -> release blocker ___ Python tracker <https://bugs.python.org/issu

[issue9504] signal.signal/signal.alarm not working as expected

STINNER Victor added the comment: https://www.python.org/dev/peps/pep-0475/ changed deeply how Python handles signals. Python now tries to restart syscalls interrupted by signals (EINTR). A Python function only raises an exception if the Python signal handler raises an exception

[issue20559] urllib/http fail to sanitize a non-ascii url

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker <https://bugs.python.org/issue20559> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14484] missing return in win32_kill?

STINNER Victor added the comment: IMO trying to mimic POSIX behavior on Windows in the single function os.kill() was a bad design idea. Windows should have its own specific function. -- ___ Python tracker <https://bugs.python.org/issue14

[issue45643] SIGSTKFLT is missing from the signals module on Linux

STINNER Victor added the comment: New changeset a62be77266b1beadd42d4952186332bc0847b7d6 by Gareth Rees in branch 'main': bpo-45643: Add signal.SIGSTKFLT on platforms where this is defined (GH-29266) https://github.com/python/cpython/commit/a62be77266b1beadd42d4952186332

[issue45643] Add signal.SIGSTKFLT constant (Linux)

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed title: SIGSTKFLT is missing from the signals module on Linux -> Add signal.SIGSTKFLT constant (Linux) ___ Python tra

[issue45643] Add signal.SIGSTKFLT constant (Linux)

STINNER Victor added the comment: I merged your PR, thanks! I'm curious how people use this signal :-) -- ___ Python tracker <https://bugs.python.org/is

[issue40927] ./python -m test test___all__ test_binhex fails

STINNER Victor added the comment: Oh thanks Irit! It's too easy to forget closing an issue! -- ___ Python tracker <https://bugs.python.org/issue40927> ___ ___

[issue30716] Failing tests with installed 3.6.2rc1 on Win 10-64

STINNER Victor added the comment: It seems like this issue has been fixed in bpo-27425. -- resolution: out of date -> duplicate superseder: -> Tests fail because of git's newline preferences on Windows ___ Python tracker <https://b

[issue21390] readline: setlocale() returns NULL on Android

STINNER Victor added the comment: Since 2014, Android got getter support for Unix locales. Since nobody was able to say if the issue still exists on Android since 2014, nor if my patch fix the issue, I perfer to close the issue as out of date. -- resolution: -> out of date st

[issue12411] cgi.parse_multipart is broken on 3.x

Change by STINNER Victor : -- nosy: -vstinner status: pending -> open ___ Python tracker <https://bugs.python.org/issue12411> ___ ___ Python-bugs-list mai

[issue23469] Delete Misc/*.wpr files

STINNER Victor added the comment: IMO it's ok to remove these files. If WING is maintained again, it will be trivial to add again these configuratin files. I suggest to only remove these files in Python 3.11. -- nosy: +vstinner ___ Python tr

[issue34624] -W option and PYTHONWARNINGS env variable does not accept module regexes

STINNER Victor added the comment: Oh, I didn't know this issue. I closed my issue bpo-43862 as a duplicate. -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/is

[issue43862] warnings: -W option and PYTHONWARNINGS now use the message as a regex

STINNER Victor added the comment: I mark this issue as a duplicate of bpo-34624. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> -W option and PYTHONWARNINGS env variable does not accept mo

[issue34624] -W option and PYTHONWARNINGS env variable does not accept module regexes

STINNER Victor added the comment: > Adding regular expression support to -W and PYTHONWARNINGS env var turns the > options into potential attack vectors. Why would an attacker control these options? If an attacker controls how Python is run, they are more efficient way to take cont

[issue34624] -W option and PYTHONWARNINGS env variable does not accept module regexes

STINNER Victor added the comment: One option is to keep the current behavior by default, but support a new "/regex/" format. The /regex/ format is commonly used in Perl and sed. Example to ignore warnings containing "deprecated" string in their message: python3 -W

[issue31370] Remove support for threads-less builds

STINNER Victor added the comment: > This has unfortunately turned out to be a blocker on getting WASI support as > there's not direct threading support in WebAssembly. This issue is now closed and unrelated to WASI support. Can you please open a new separated i

[issue31370] Remove support for threads-less builds

STINNER Victor added the comment: Either reopen the issue or open a new issue. Only people subscribed to this bug are aware of the recent comments. Closed issues are hidden from the bugs home page and from the default search. If you consider that Python must again support thread-less

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

Change by STINNER Victor : -- pull_requests: +28342 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30123 ___ Python tracker <https://bugs.python.org/issu

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: I created PR 30123 to fix _PyUnicode_EqualToASCIIId() and type update_slot() functions. I added comments explaining why we can no longer optimize the comparison of two interned string objects. -- ___ Python

[issue40533] [subinterpreters] Don't share Python objects between interpreters

STINNER Victor added the comment: Until all Python stdlib C extensions and all third-party C extensions will be modified to no longer use and define static types and will stop shared Python objects between two interpreters, we can no longer micro-optimize the comparison of two interned

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: These bug prevent the Fedora infra team from upgrading the Koji builders to Fedora 35. Koji runs on mod_wsgi which is affected by the bug: https://bugzilla.redhat.com/show_bug.cgi?id=2030621#c1 -- ___ Python

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: See also bpo-46070: I don't know if it's related. -- ___ Python tracker <https://bugs.python.org/issue46006> ___ ___

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: Mark: "As Victor points out, there is no bug in 3.9 because interned strings are common across all interpreter. We should revert that behavior." The rationale for having per-interpreter interned strings and per-interpreter _Py_IDENTIFIER() stri

[issue41682] [Windows] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker <https://bugs.python.org/issue41682> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46070] broken subinterpreters

STINNER Victor added the comment: I can sometimes reproduce the crash on Windows with Python 3.9. Call stack (most recent to oldest frames): * PyObject_GC_UnTrack() - crash on _PyGCHead_SET_NEXT(prev, next) because prev is dangling pointer (0x1fe64dd5250), Visual Studio is unable to read

[issue46070] broken subinterpreters

STINNER Victor added the comment: Using attached bug.py, it's possible to trigger the crash on the main branch. I modified the reproducer to use the "_asyncio" extension which still uses the old API PyModule_Create() with PyModuleDef.m_size = -1. -- Ad

[issue46070] _PyImport_FixupExtensionObject() regression causing a crash in subintepreters

Change by STINNER Victor : -- title: broken subinterpreters -> _PyImport_FixupExtensionObject() regression causing a crash in subintepreters ___ Python tracker <https://bugs.python.org/issu

[issue46070] _PyImport_FixupExtensionObject() regression causing a crash in subintepreters

STINNER Victor added the comment: Hum, maybe bug.py exposes a different kind of bug. The _asyncio extension uses a non-trivial initialize code which doesn't seem to handle well concurrent "import _asyncio". -- ___ Python

[issue46070] _PyImport_FixupExtensionObject() regression causing a crash in subintepreters

STINNER Victor added the comment: Fedora issue: https://bugzilla.redhat.com/show_bug.cgi?id=2034962 -- ___ Python tracker <https://bugs.python.org/issue46

[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash

STINNER Victor added the comment: If the issue is about how pyperformance creates its virtual environment (how setuptools is installed), I suggest to continue discussion the issue in pyperformance: https://github.com/python/pyperformance/issues

[issue46142] python --help output is too long

STINNER Victor added the comment: initconfig.c parses all -X options. preconfig.c also checks for a few specific -X options which are also checked in initconfig.c. My notes on parsing command line options: https://pythondev.readthedocs.io/pyconfig.html#add-a-new-command-line-option

[issue46178] Remove `.travis.yml`?

STINNER Victor added the comment: I had so many troubles with Travis CI. I'm happy that GitHub Actions is more reliable and that Travis CI is gone. -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/is

[issue46205] Race condition in runtest_mp leads to hangs (never exits)

STINNER Victor added the comment: Do you want to work on a fix? -- ___ Python tracker <https://bugs.python.org/issue46205> ___ ___ Python-bugs-list mailin

[issue46205] test.libregrtest: Race condition in runtest_mp leads to hangs (never exits)

Change by STINNER Victor : -- components: +Tests title: Race condition in runtest_mp leads to hangs (never exits) -> test.libregrtest: Race condition in runtest_mp leads to hangs (never exits) ___ Python tracker <https://bugs.python.org/issu

[issue46070] _PyImport_FixupExtensionObject() regression causing a crash in subintepreters

STINNER Victor added the comment: I applied PR 30123 of bpo-46006: "./python bug.py" does still crash. So bpo-46006 is unrelated to this issue. -- ___ Python tracker <https://bugs.python.o

[issue46070] _PyImport_FixupExtensionObject() regression causing a crash in subintepreters

STINNER Victor added the comment: bug.py: * Python 3.7 branch doesn't crash * Python 3.8 branch does crash So the regression was introduced in Python 3.8. git bisect points me to this change: --- commit 13915a3100608f011b29da2f3716c990f523b631 (refs/bisect/bad) Author: Miss Islington

[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)

Change by STINNER Victor : -- title: _PyImport_FixupExtensionObject() regression causing a crash in subintepreters -> [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression) ___ Python tracker <

[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)

STINNER Victor added the comment: > bpo-36356: Fix memory leak in _asynciomodule.c (GH-16598) Python 3.8.0 is the first Python version containing this change. So it looks like a Python 3.8 regression. -- ___ Python tracker <

[issue40521] [subinterpreters] Make free lists and unicode caches per-interpreter

Change by STINNER Victor : -- pull_requests: +28626 pull_request: https://github.com/python/cpython/pull/30422 ___ Python tracker <https://bugs.python.org/issue40

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

Change by STINNER Victor : -- pull_requests: +28627 pull_request: https://github.com/python/cpython/pull/30422 ___ Python tracker <https://bugs.python.org/issue46

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: IMO writing a complete rationale for running multiple interpreters in parallel which require a whole PEP. I didn't write such PEP yet since there are still non-trivial technical issues, especially the problem of static types: bpo-40601. I don't

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: New changeset 35d6540c904ef07b8602ff014e520603f84b5886 by Victor Stinner in branch 'main': bpo-46006: Revert "bpo-40521: Per-interpreter interned strings (GH-20085)" (GH-30422) https://github.com/p

[issue40521] [subinterpreters] Make free lists and unicode caches per-interpreter

STINNER Victor added the comment: New changeset 35d6540c904ef07b8602ff014e520603f84b5886 by Victor Stinner in branch 'main': bpo-46006: Revert "bpo-40521: Per-interpreter interned strings (GH-20085)" (GH-30422) https://github.com/p

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

Change by STINNER Victor : -- pull_requests: +28630 pull_request: https://github.com/python/cpython/pull/30425 ___ Python tracker <https://bugs.python.org/issue46

[issue40521] [subinterpreters] Make free lists and unicode caches per-interpreter

Change by STINNER Victor : -- pull_requests: +28631 pull_request: https://github.com/python/cpython/pull/30425 ___ Python tracker <https://bugs.python.org/issue40

[issue46277] '''...''' error

STINNER Victor added the comment: vstinner@apu$ python3 Python 3.10.1 (main, Dec 9 2021, 00:00:00) [GCC 11.2.1 20211203 (Red Hat 11.2.1-7)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> str_='

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

Change by STINNER Victor : -- pull_requests: +28639 pull_request: https://github.com/python/cpython/pull/30433 ___ Python tracker <https://bugs.python.org/issue46

[issue40521] [subinterpreters] Make free lists and unicode caches per-interpreter

Change by STINNER Victor : -- pull_requests: +28640 pull_request: https://github.com/python/cpython/pull/30433 ___ Python tracker <https://bugs.python.org/issue40

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: New changeset 72c260cf0c71eb01eb13100b751e9d5007d00b70 by Victor Stinner in branch '3.10': [3.10] bpo-46006: Revert "bpo-40521: Per-interpreter interned strings (GH-20085)" (GH-30422) (GH-30425) https://github.com/p

[issue40521] [subinterpreters] Make free lists and unicode caches per-interpreter

STINNER Victor added the comment: New changeset 72c260cf0c71eb01eb13100b751e9d5007d00b70 by Victor Stinner in branch '3.10': [3.10] bpo-46006: Revert "bpo-40521: Per-interpreter interned strings (GH-20085)" (GH-30422) (GH-30425) https://github.com/p

[issue46283] [subinterpreters] Unicode interned strings must not be shared between interpreters

Change by STINNER Victor : -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue46283> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46283] [subinterpreters] Unicode interned strings must not be shared between interpreters

New submission from STINNER Victor : My commit ea251806b8d11b30d2182af1e589caf88acf made Unicode interned strings per interpreter to avoid accessing the same Python object from two different interpreters, to avoid race conditions on its reference count. Problem: the change introduced the

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

STINNER Victor added the comment: _PyUnicode_EqualToASCIIId() and type update_slot() functions are fixed in 3.10 and main branches. The regression is now fixed. But the revert reintroduces the issue on subinterpreters, so I created bpo-46283: "[subinterpreters] Unicode interned strings

[issue40521] [subinterpreters] Make free lists and unicode caches per-interpreter

STINNER Victor added the comment: My commit ea251806b8d11b30d2182af1e589caf88acf (interned strings) introduced bpo-46006 "[subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters" regression. To unblock the Python 3.11.0a4 release, I just reverted the

[issue46142] python --help output is too long

STINNER Victor added the comment: "xoptions" name comes from sys._xoptions (Python) and PyConfig.xoptions (C). Oh, sys._xoptions is a private API... but it's mentioned in the -X documentation: https://docs.python.org/3/using/cmdline.h

[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)

STINNER Victor added the comment: New changeset b127e70a8a682fe869c22ce04c379bd85a00db67 by Erlend Egeberg Aasland in branch 'main': bpo-46070: Fix asyncio initialisation guard (GH-30423) https://github.com/python/cpython/commit/b127e70a8a682fe869c22ce04c379b

[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)

STINNER Victor added the comment: Even with PR 30454, I can still reproduce the crash on Python 3.9 (randomly, it takes a few attempts to reproduce the crash): vstinner@DESKTOP-DK7VBIL C:\vstinner\python\3.9>python -X dev win_py399_crash_reproducer.py Running Debug|x64 interpreter... e

[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)

STINNER Victor added the comment: > The problematic change could be (d0d29655ff) affecting import.c This change is part of the 3.10 branch. For 3.9, git bisect tells me that it's the following change: commit 52d9d3b75441ae6038fadead89eac5eecdd34501 Author: Łukasz Langa Date: Tue

[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)

STINNER Victor added the comment: I reverted manually the commit 52d9d3b75441ae6038fadead89eac5eecdd34501 (in my local Python 3.9 checkout): I confirm that the revert fix the win_py399_crash_reproducer.py crash in Python 3.9. -- ___ Python

[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)

STINNER Victor added the comment: In the 3.9 branch, the commit 4d2cfd354969590ba8e0af0447fd84f8b5e61952 fixed the _asyncio extension. win_py399_crash_reproducer.py still branch on Windows in the 3.9 branch. The code can be simplified with: code = "import _sre" Moreover,

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

STINNER Victor added the comment: The bpo-46295 was marked as a duplicate of this issue. -- ___ Python tracker <https://bugs.python.org/issue15751> ___ ___ Pytho

[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)

STINNER Victor added the comment: The _sre crash has a complex history in the 3.9 branch: * (1) 2019-11-20, commit 7247407c35330f3f6292f1d40606b7ba6afd5700: first CRASH! The parent commit (488d02a24142948bfb1fafd19fa48e61fcbbabc5) doesn't crash. * (2) 2019-11-22, c

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

Change by STINNER Victor : -- title: [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression) -> [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression) ___ Pyt

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

STINNER Victor added the comment: This bug is hard to reproduce for different reasons: * It occurs randomly: I need between 1 and 50 attempts to reproduce the bug using win_py399_crash_reproducer.py * So far, the bug was only reproduced on Windows. * I failed to reproduce the crash on

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

Change by STINNER Victor : -- pull_requests: +28688 pull_request: https://github.com/python/cpython/pull/30484 ___ Python tracker <https://bugs.python.org/issue46

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: It's not the first time that private functions included by the public Python.h are causing build errors event if these functions are not used. The previous issue were functions for atomic operations. I solved this build error by moving the whole priv

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46323] Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker <https://bugs.python.org/issue46323> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46142] python --help output is too long

STINNER Victor added the comment: > Serhiy: What do you think about -hh (and maybe —help-full) printing full help? Do you know other projects which dump the full help into stdout when asking for the "full help"? For me, the best CLI is "git help", "git help init&

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: New changeset ea1a54506b4ac38b712ba63ec884292025f16111 by Victor Stinner in branch 'main': bpo-46303: Move fileutils.h private functions to internal C API (GH-30484) https://github.com/python/cpython/commit/ea1a54506b4ac38b712ba63ec88429

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

Change by STINNER Victor : -- pull_requests: +28729 pull_request: https://github.com/python/cpython/pull/30528 ___ Python tracker <https://bugs.python.org/issue46

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: > While attempting to embed the full cpython source in my application, I found > that during compilation on Windows, there was a compilation issue due to > struct stat not being defined. Do you get the error when building Python? Or on #include w

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: Python.h indirectly (via fileutils.h) defines _Py_wstat() and _Py_stat() functions which use the "struct stat*" type for 12 years: commit 4e31443c4d2c1fb211a6ea90fc6a8fbd9ff81c97 Author: Victor Stinner Date: Thu Oct 7 21:45:39 2010 +

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

Change by STINNER Victor : -- pull_requests: +28739 pull_request: https://github.com/python/cpython/pull/30539 ___ Python tracker <https://bugs.python.org/issue46

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: It seems like _Py_stat() and _Py_wstat() are only needed on non-Windows platforms: only the _get_tcl_lib_path() function of Modules/_tkinter.c uses _Py_stat(). I wrote PR 30539 to not define _Py_stat() and _Py_wstat() on Windows

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

Change by STINNER Victor : -- pull_requests: +28751 pull_request: https://github.com/python/cpython/pull/30550 ___ Python tracker <https://bugs.python.org/issue46

[issue46346] New compilation warnings on Windows

STINNER Victor added the comment: Oh right, I introduced these warnings in bpo-46303. Let's continue the discussion there. -- dependencies: -_Py_stat and _Py_wstat using incorrect type for status argument priority: release blocker -> resolution: -> duplicate stage:

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: I marked bpo-46346 as a duplicate of this issue. Copy of the first message: """ I am getting these warnings: C:\Users\gvanrossum\cpython\PC\_testconsole.c(70,38): warning C4013: '_Py_get_osfhandle' undefined; assuming extern

[issue46347] memory leak in PyEval_EvalCodeEx

STINNER Victor added the comment: The memory leak has been fixed in 3.10 and main branches. Can this issue be closed now? -- components: +Interpreter Core versions: +Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: New changeset 08bc1bad11cad39f508bd662c9b28fcd9c995512 by Victor Stinner in branch 'main': bpo-46303: Fix fileutils.h compiler warnings (GH-30550) https://github.com/python/cpython/commit/08bc1bad11cad39f508bd662c9b28f

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: Christian Heimes: "I set the release blocker flag for the ticket." It's just a compiler warning, why marking it as a release blocker? Anyway, it's now fixed. -- priority: release blocker -> ___

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: Paul: Can you please try to build the main branch of Python with clang and tell me if you still have the compiler warnings? If yes, can you please copy/paste the compiler warnings? Do you build Python on Windows or from another OS (cross-compilation

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: If possible, I would prefer to not change 3.9 and 3.10 to avoid any risk of introducing a *new* build error, while trying to support a new platform. I don't think that we currently supporting build Python with clang on Window

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: > Hi Victor, I was trying to compile with clang on Windows 10. I will try to > pull your 3.11 changes and test. Sorry to cause so much churn. It looked to > me like a simple issue that was missed, probably because whatever was trying > to com

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

STINNER Victor added the comment: > Seems it would go back to depending on some type nonstandard python macro to > translate between the two during build. In the internal C API, there are less concerns about writing portable code. We expect users of this API to pay more attention t

[issue46303] Building Python with clang on Windows fails on _Py_stat(): struct stat is not defined

STINNER Victor added the comment: Paul Campbell: "The changes in the main branch gets me past this issue without having to make additional changes." Ok, nice. I close the issue. I consider that building Python with clang is a new feature. I prefer to not backport these changes

[issue44133] Some C-API symbols (e.g. Py_FrozenMain) are not always exported

Change by STINNER Victor : -- pull_requests: +28757 pull_request: https://github.com/python/cpython/pull/30556 ___ Python tracker <https://bugs.python.org/issue44

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

New submission from STINNER Victor : Python 3.11 made many changes in PyFrameObject and PyThreadState structures. Code which accessed directly structure members doesn't build anymore. For example, "frame->f_code" is now fails because PyFrameObject.f_code member is done. I p

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

Change by STINNER Victor : -- keywords: +patch pull_requests: +28759 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30558 ___ Python tracker <https://bugs.python.org/issu

[issue44133] Some C-API symbols (e.g. Py_FrozenMain) are not always exported

STINNER Victor added the comment: > On Solaris (and most likely several other platforms), > `PyThread_get_thread_native_id` is also not available. Oh, I added an explicit test for that in my PR 30556. > `Py_FrozenMain` should be added to stable ABI I suggest to first fix the issu

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

New submission from STINNER Victor : C extensions written for Python 3.10 and older which access directly to the PyFrameObject.f_back member build successfully on Python 3.11, but they can fail because f_back must not be read directly. f_back can be NULL even if the frame has an outer frame

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

STINNER Victor added the comment: > f_lineno: changed, use PyFrame_GetLineNumber() Oh I was wrong, PyFrame_GetLineNumber() code is the same in Python 3.10. It was already a bad idea to read directly the f_lineno member in Python 3.10: PyFrame_GetLineNumber() should always be cal

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

STINNER Victor added the comment: It's unclear to me if the ability to read directly the PyFrameObject.f_lineno member is a deliberate use case, or if we should enforce the usage of PyFrame_GetLineNumber(). -- ___ Python tracker &

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

STINNER Victor added the comment: > I don't know how we can stop people from using them though. The first option is to promote helper functions to abstract access to the PyFrameObject structure. The second option is to make the whole structure opaque and enforce the usage o

  1   2   3   4   5   6   7   8   9   10   >