[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

Change by Eric Snow : -- nosy: +Mark.Shannon ___ Python tracker <https://bugs.python.org/issue47185> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: Looks like gh-32218 worked. -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue47146> ___ ___ Python-

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: Specifically: https://github.com/python/cpython/actions/workflows/build.yml. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issu

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: I'll keep an eye on PRs for the next day or so. -- resolution: -> fixed stage: patch review -> resolved status: open -> pending ___ Python tracker <https://bugs.python.or

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: New changeset e7bb7c2f047b4f97e4426c42ae209c969808069d by Eric Snow in branch 'main': bpo-47146: Stop Depending On regen-deepfreeze For regen-global-objects (gh-32218) https://github.com/python/cpython/commit/e7bb7c2f047b4f97e4426c42ae209c969808069d

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Change by Eric Snow : -- pull_requests: +30294 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32218 ___ Python tracker <https://bugs.python.org/issu

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: Brandt pointed out this is consistently reproducible locally: make clean regen-all -j I'll get this sorted out today. -- ___ Python tracker <https://bugs.python.org/issue47

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: I re-ran jobs that had failed before I merged that gh-32206. Several passed, but the following are still failing: * https://github.com/python/cpython/pull/32188 + https://github.com/python/cpython/runs/5773938424 * https://github.com/python/cpython/pull/32132

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: New changeset db4dada5108dd49ebca23e4559a53630a2df8447 by Eric Snow in branch 'main': bpo-47146: Avoid Using make Recursively (gh-32206) https://github.com/python/cpython/commit/db4dada5108dd49ebca23e4559a53630a2df8447

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Change by Eric Snow : -- pull_requests: +30281 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32206 ___ Python tracker <https://bugs.python.org/issu

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: Looks like this is still an intermittent problem: * https://github.com/python/cpython/pull/32195 + failed: https://github.com/python/cpython/runs/5756616733 + failed: https://github.com/python/cpython/runs/5753267869 + failed: https://github.com/python

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: Looks like that fixed it, per https://github.com/python/cpython/pull/32134. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: New changeset 4c116f716bd1c174d6530b9a7a5ed3863927a109 by Eric Snow in branch 'main': bpo-47146: Eliminate a race between make regen-deepfreeze and make regen-global-objects. (gh-32162) https://github.com/python/cpython/commit

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Change by Eric Snow : -- keywords: +patch pull_requests: +30240 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32162 ___ Python tracker <https://bugs.python.org/issu

[issue47146] PR check "Check if generated files are up to date" failing intermittently

Eric Snow added the comment: There's probably something racy with make. See: https://github.com/python/cpython/runs/5712538599?check_suite_focus=true#step:10:1147 -- ___ Python tracker <https://bugs.python.org/issue47

[issue47146] PR check "Check if generated files are up to date" failing intermittently

New submission from Eric Snow : The "Check if generated files are up to date" GitHub check for PRs has been failing recently. It may also impact local usage of "make regen-all". Example: https://github.com/python/cpython/runs/5719012664 This may be related to gh-32061.

[issue46712] Share global string identifiers in deepfreeze

Eric Snow added the comment: New changeset febf54bcf3fdc45ad84b4073e24bbaaee0ac8b2a by Eric Snow in branch 'main': bpo-46712: Do not Regen Deep-Frozen Modules before Generating Global Objects (gh-32061) https://github.com/python/cpython/commit/febf54bcf3fdc45ad84b4073e24bbaaee0ac8b2a

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

Eric Snow added the comment: New changeset 21412d037b07c08266e96dfd0c0e44a1b7693bc1 by Eric Snow in branch 'main': bpo-46541: Add a Comment About When to Use _Py_DECLARE_STR(). (gh-32063) https://github.com/python/cpython/commit/21412d037b07c08266e96dfd0c0e44a1b7693bc1

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

Change by Eric Snow : -- pull_requests: +30154 pull_request: https://github.com/python/cpython/pull/32063 ___ Python tracker <https://bugs.python.org/issue46

[issue46964] The global config should not be stored on each interpreter

Eric Snow added the comment: Here are reasons why PyConfig relates to the runtime and not each interpreter: * PyConfig was introduced so embedders could dictate how the *runtime* should be initialized * after initialization, it represents how the runtime was initialized * in the public API

[issue46712] Share global string identifiers in deepfreeze

Change by Eric Snow : -- pull_requests: +30151 pull_request: https://github.com/python/cpython/pull/32061 ___ Python tracker <https://bugs.python.org/issue46

[issue46712] Share global string identifiers in deepfreeze

Eric Snow added the comment: > After a new `&_Py_ID(__orig_class__)` is added to > Objects/genericaliasobject.c, running `make regen-global-objects` starts > > gcc -pthread -c [snipped] -DPy_BUILD_CORE -o Objects/genericaliasobject.o > Objects/genericaliasobjec

[issue46964] The global config should not be stored on each interpreter

Change by Eric Snow : -- keywords: +patch pull_requests: +29879 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31771 ___ Python tracker <https://bugs.python.org/issu

[issue46964] The global config should not be stored on each interpreter

New submission from Eric Snow : tl;dr let's move PyInterpreterState.config to _PyRuntimeState.config. Historically the runtime has been initialized using Py_Initialize(). PEP 587 added Py_InitializeFromConfig(), which takes a PyConfig and allows all sorts of customization of the runtime

[issue46712] Share global string identifiers in deepfreeze

Eric Snow added the comment: New changeset 21099fc064c61d59c936a2f6a0db3e07cd5c8de5 by Eric Snow in branch 'main': bpo-46712: Let generate_global_objects.py Run on Earlier Python Versions (gh-31637) https://github.com/python/cpython/commit/21099fc064c61d59c936a2f6a0db3e07cd5c8de5

[issue46890] venv does not create "python" link in python 3.11

Eric Snow added the comment: This may be related to the getpath.py work Steve did. -- nosy: +eric.snow, steve.dower ___ Python tracker <https://bugs.python.org/issue46

[issue46712] Share global string identifiers in deepfreeze

Change by Eric Snow : -- pull_requests: +29759 pull_request: https://github.com/python/cpython/pull/31637 ___ Python tracker <https://bugs.python.org/issue46

[issue46753] Statically allocate and initialize the empty tuple.

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

[issue46886] pyexpat occasionally fails to build on the ARM64 Windows Non-Debug 3.x buildbot

New submission from Eric Snow : example: https://buildbot.python.org/all/#/builders/730/builds/4081 -- components: Build messages: 414223 nosy: eric.snow, vstinner priority: normal severity: normal stage: needs patch status: open title: pyexpat occasionally fails to build on the ARM64

[issue46753] Statically allocate and initialize the empty tuple.

Eric Snow added the comment: New changeset 08deed1af56bec8668c6cb4d5cfd89e393e1fe5e by Eric Snow in branch 'main': bpo-46753: Add the empty tuple to the _PyRuntimeState.global_objects. (gh-31345) https://github.com/python/cpython/commit/08deed1af56bec8668c6cb4d5cfd89e393e1fe5e

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

Eric Snow added the comment: Thanks for working on this, Victor. -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue45316> ___ ___ Python-bug

[issue46806] Overlapping PYTHONPATH may cause import already imported module

Eric Snow added the comment: FYI, a technical solution has been discussed before: bpo-13475 and PEP 395. However, that does not help so much if the default behavior isn't changed. That would require a PEP but I expect it would be rejected because so many scripts already rely

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

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

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

Eric Snow added the comment: New changeset 1f455361ecfb1892e375bdbee813cdf095b6cfb8 by Eric Snow in branch 'main': bpo-46765: Replace Locally Cached Strings with Statically Initialized Objects (gh-31366) https://github.com/python/cpython/commit/1f455361ecfb1892e375bdbee813cdf095b6cfb8

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

Eric Snow added the comment: Thanks for the updates, Eddie. -- ___ Python tracker <https://bugs.python.org/issue40255> ___ ___ Python-bugs-list mailin

[issue46806] Overlapping PYTHONPATH may cause import already imported module

Eric Snow added the comment: I'm leaving this "pending" in case there may be some improvement we can make to the documentation to address this. -- components: +Interpreter Core nosy: +docs@python status: open -> pending ___ Python tr

[issue46806] Overlapping PYTHONPATH may cause import already imported module

Eric Snow added the comment: Here is more detail on what happens when "from src import user_1, user_2, user_3" is executed in main.py: 1. the "src" module is imported a. not found in sys.modules b. file found on a sys.path entry (the directory main.py is in)

[issue46806] Overlapping PYTHONPATH may cause import already imported module

Eric Snow added the comment: When you run a Python script, the directory the script is in is automatically added to the beginning of sys.path. This is the fundamental issue you've run into. Basically, "src.common_object" is imported relative to the "src" that wa

[issue41111] [C API] Convert a few stdlib extensions to the limited C API (PEP 384)

Change by Eric Snow : -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43974] Define Py_BUILD_CORE_MODULE in extensions instead of setup.py and Modules/Setup

Change by Eric Snow : -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue43974> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Eric Snow added the comment: (from https://github.com/python/cpython/pull/31376#issuecomment-1041836106) [corona10] > Should we create the separate bpo issue if module changes are too noisy? I think it's fine to use the one issue. There are only 26 modules with `NEEDS_PY_IDENTIF

[issue46772] Statically Initialize PyArg_Parser in clinic.py

Change by Eric Snow : -- dependencies: +Add a Private API for Looking Up Global Objects, Statically allocate and initialize the empty tuple. ___ Python tracker <https://bugs.python.org/issue46

[issue46773] Add a Private API for Looking Up Global Objects

New submission from Eric Snow : We need this to statically initialize PyArg_Parser.kwtuple. (See bpo-46772.) For now this will be a "private" API (leading underscore). Ultimately, we'll want a Public API, so we can eventually stop exposing *any* objects as symbols in the C-API

[issue46772] Statically Initialize PyArg_Parser in clinic.py

New submission from Eric Snow : The code generated by clinic.py is already partially statically initialized. Currently we init the other fields in Python/getargs.c:parser_init(), which runs the first time we try to use each parser. AFAICS, that remaining init that could be done statically

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

Change by Eric Snow : -- keywords: +patch pull_requests: +29516 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31366 ___ Python tracker <https://bugs.python.org/issu

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

New submission from Eric Snow : This removes a number of static variables and is a little more efficient. -- assignee: eric.snow components: Interpreter Core messages: 413313 nosy: eric.snow priority: normal severity: normal stage: needs patch status: open title: Replace Locally Cached

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

Eric Snow added the comment: New changeset 4d8a515d193a4c9f3844704f974ddb870d7ee383 by Eric Snow in branch 'main': bpo-46541: Scan Fewer Files in generate_global_objects.py (gh-31364) https://github.com/python/cpython/commit/4d8a515d193a4c9f3844704f974ddb870d7ee383

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

Eric Snow added the comment: New changeset 6c8958948666403f2370ca7b4c0a52b2010ec16d by Eric Snow in branch 'main': bpo-46541: Drop the check for orphaned global strings. (gh-31363) https://github.com/python/cpython/commit/6c8958948666403f2370ca7b4c0a52b2010ec16d

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

Change by Eric Snow : -- pull_requests: +29514 pull_request: https://github.com/python/cpython/pull/31364 ___ Python tracker <https://bugs.python.org/issue46

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

Change by Eric Snow : -- pull_requests: +29513 pull_request: https://github.com/python/cpython/pull/31363 ___ Python tracker <https://bugs.python.org/issue46

[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

[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 <https://bugs.python.org/issue46

[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 <https://bugs.python.org/issu

[issue46753] Statically allocate and initialize the empty tuple.

Eric Snow added the comment: Also see bpo-45953. -- ___ Python tracker <https://bugs.python.org/issue46753> ___ ___ 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 <https://bugs.python.org/issue46

[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 <https://bugs.python.org/issue46541> ___ ___ Python-bugs-list m

[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

[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

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

Eric Snow added the comment: On Fri, Feb 11, 2022 at 1:36 AM Christoph Reiter wrote: > Sorry if off topic, but I noticed that CPython doesn't deprecate macros in > code, while with gcc/clang it's possible to show compiler warnings for them > using some pragma magic: > [s

[issue36876] [subinterpreters] Global C variables are a problem

Eric Snow added the comment: New changeset 80e4f262aa27a39abf3fadc19a6323fea4607a8f by Eric Snow in branch 'main': bpo-36876: Make sure the c-analyzer is checking all the source files.' (gh-31264) https://github.com/python/cpython/commit/80e4f262aa27a39abf3fadc19a6323fea4607a8f

[issue36876] [subinterpreters] Global C variables are a problem

Change by Eric Snow : -- pull_requests: +29430 pull_request: https://github.com/python/cpython/pull/31264 ___ Python tracker <https://bugs.python.org/issue36

[issue36876] [subinterpreters] Global C variables are a problem

Eric Snow added the comment: New changeset cb68788dcadf43b47292bab7816a5ed9efa69730 by Eric Snow in branch 'main': bpo-36876: Minor cleanup to c-analyzer "ignored" data.' (gh-31239) https://github.com/python/cpython/commit/cb68788dcadf43b47292bab7816a5e

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

Eric Snow added the comment: @Eddie, what can I do to push this forward? FYI, in addition to the python-dev thread a few weeks back, I've brought the matter up with the steering council. [1] Also, if we can get back to performance-neutral (currently at about 4% slower) then there would

[issue36876] [subinterpreters] Global C variables are a problem

Change by Eric Snow : -- pull_requests: +29409 pull_request: https://github.com/python/cpython/pull/31239 ___ Python tracker <https://bugs.python.org/issue36

[issue36876] [subinterpreters] Global C variables are a problem

Eric Snow added the comment: New changeset 77bab59c8a1f04922bb975cc4f11e5323d1d379d by Eric Snow in branch 'main': bpo-36876: Update the c-analyzer whitelist. (gh-31225) https://github.com/python/cpython/commit/77bab59c8a1f04922bb975cc4f11e5323d1d379d

[issue36876] [subinterpreters] Global C variables are a problem

Change by Eric Snow : -- pull_requests: +29396 pull_request: https://github.com/python/cpython/pull/31225 ___ Python tracker <https://bugs.python.org/issue36

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

Eric Snow added the comment: New changeset 81c72044a181dbbfbf689d7a977d0d99090f26a8 by Eric Snow in branch 'main': bpo-46541: Replace core use of _Py_IDENTIFIER() with statically initialized global objects. (gh-30928) https://github.com/python/cpython/commit

[issue45952] Tools/c-analyzer is out-of-date.

Eric Snow added the comment: New changeset c018d3037b5b62e6d48d5985d1a37b91762fbffb by Eric Snow in branch 'main': bpo-45952: Get the C analyzer tool working again. (gh-31220) https://github.com/python/cpython/commit/c018d3037b5b62e6d48d5985d1a37b91762fbffb

[issue45952] Tools/c-analyzer is out-of-date.

Change by Eric Snow : -- pull_requests: +29390 pull_request: https://github.com/python/cpython/pull/31220 ___ Python tracker <https://bugs.python.org/issue45

[issue45952] Tools/c-analyzer is out-of-date.

Eric Snow added the comment: New changeset 1e6214dbd6a980b47123229aefd60bb2c9341b53 by Eric Snow in branch 'main': bpo-45952: Get the C analyzer tool working again. (gh-31219) https://github.com/python/cpython/commit/1e6214dbd6a980b47123229aefd60bb2c9341b53

[issue45952] Tools/c-analyzer is out-of-date.

Change by Eric Snow : -- pull_requests: +29389 pull_request: https://github.com/python/cpython/pull/31219 ___ Python tracker <https://bugs.python.org/issue45

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

Eric Snow added the comment: (thanks Victor: https://mail.python.org/archives/list/python-...@python.org/message/7RMLIJHUWVBZFV747TFEHOE6LNBVQSMM/) 3rd party use of _Py_IDENTIFIER(): * blender + https://github.com/blender/blender/blob/master/source/blender/python/intern/bpy_traceback.c

[issue41962] Make threading._register_atexit public?

Eric Snow added the comment: > This means that ThreadPoolExecutor's atexit runs before mine, > and since I never get a chance to cancel my tasks, it deadlocks. (assuming we want to support long-running tasks here) With all the above in mind, there are a few things that may help. The

[issue41962] Make threading._register_atexit public?

Eric Snow added the comment: FWIW, here's a brain dump about ThreadPoolExecutor and its atexit handler after having looked at the code. First, the relationship between the objects involved: * work item -> Future * work item -> task (e.g. function) * queue -> [work item]

[issue41962] Make threading._register_atexit public?

Eric Snow added the comment: > I'm running some long-running (possibly infinite) tasks in the thread pool, > and I cancel them in an `atexit` callback Alternately, perhaps ThreadPoolExecutor isn't the right fit here, as implied by the route you ended up going. It seems like it's no

[issue41962] Make threading._register_atexit public?

Eric Snow added the comment: > I'm running some long-running (possibly infinite) tasks in the thread pool, > and I cancel them in an `atexit` callback To be clear, by "cancel" you are not talking about Future.cancel(). Rather, your handler causes all running tasks to fi

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

Eric Snow added the comment: FYI, I've posted to python-dev for feedback before proceeding: https://mail.python.org/archives/list/python-...@python.org/thread/DNMZAMB4M6RVR76RDZMUK2WRLI6KAAYS/ -- ___ Python tracker <https://bugs.python.

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

Eric Snow added the comment: If necessary, we can keep _Py_IDENTIFIER() (and the functions). Regardless, we can stop using it internally. -- ___ Python tracker <https://bugs.python.org/issue46

[issue45953] Statically allocate interpreter states as much as possible.

Change by Eric Snow : -- pull_requests: +29221 pull_request: https://github.com/python/cpython/pull/31038 ___ Python tracker <https://bugs.python.org/issue45

[issue45953] Statically allocate interpreter states as much as possible.

Eric Snow added the comment: > Any chance we could revert the recent renaming of tstate.exc_state and > tstate.root_cframe Yeah, I'll sort this out. Sorry for that. -- ___ Python tracker <https://bugs.python.org/i

[issue46524] test_peg_generator takes 8 minutes on Windows

Eric Snow added the comment: On Tue, Jan 25, 2022 at 4:14 PM STINNER Victor wrote: > Currently, most CI run "make buildbottest" which uses -r option of > libregrtest: randomize tests order. How hard would it be to first randomize the list and then move the slow tests up to a

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

Eric Snow added the comment: New changeset 247480a21cb165efdacc346a2d589dfc27e18283 by Eric Snow in branch 'main': bpo-46541: Generate the global objects initializer. (gh-30941) https://github.com/python/cpython/commit/247480a21cb165efdacc346a2d589dfc27e18283

[issue46166] Get "self" args or non-null co_varnames from frame object with C-API

Eric Snow added the comment: In addition to what Mark said, note that co_varnames get's populated lazily by the Python-level getter for code.co_varnames. So could you call the Python function before entering the hot path? Regardless, a dedicated C-API for this like Mark suggested would

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

Change by Eric Snow : -- keywords: +patch pull_requests: +29120 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/30941 ___ Python tracker <https://bugs.python.org/issu

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

Eric Snow added the comment: ## Background ## `_Py_Identifier` (and `_Py_IDENTIFIER()`, etc.) was added in 2011 [1][2] for several reasons: * provide a consistent approach for a common optimization: caching C-string based string objects * facilitate freeing those objects during runtime

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

New submission from Eric Snow : `_Py_Identifier` has been useful but at this point there is a faster and simpler approach we could take as a replacement: statically initialize the objects as fields on `_PyRuntimeState` and reference them directly through a macro. This would involve

[issue46449] Deep-freezed modules create inconsistency in sys.gettotalrefcount() (_Py_Reftotal)

Eric Snow added the comment: > the deep-frozen objects also reference the small ints directly, as well as > the singleton for b"". > Is this even safe across Py_Finalize()/Py_Initialize()? If not, we'll need to > roll that back as well. The small ints and the empty

[issue45953] Statically allocate interpreter states as much as possible.

Eric Snow added the comment: New changeset 322f962f3ee31d0dbde99e36379de8488ccc6804 by Eric Snow in branch 'main': bpo-45953: Statically initialize all the non-object PyInterpreterState fields we can. (gh-30589) https://github.com/python/cpython/commit

[issue45953] Statically allocate interpreter states as much as possible.

Eric Snow added the comment: New changeset 324908ba936d5d262026deebb81f050803848c41 by Eric Snow in branch 'main': bpo-45953: Statically initialize all the PyThreadState fields we can. (gh-30590) https://github.com/python/cpython/commit/324908ba936d5d262026deebb81f050803848c41

[issue45953] Statically allocate interpreter states as much as possible.

Change by Eric Snow : -- pull_requests: +28788 pull_request: https://github.com/python/cpython/pull/30590 ___ Python tracker <https://bugs.python.org/issue45

[issue45953] Statically allocate interpreter states as much as possible.

Change by Eric Snow : -- pull_requests: +28787 pull_request: https://github.com/python/cpython/pull/30589 ___ Python tracker <https://bugs.python.org/issue45

[issue45953] Statically allocate interpreter states as much as possible.

Change by Eric Snow : -- pull_requests: +28786 pull_request: https://github.com/python/cpython/pull/30588 ___ Python tracker <https://bugs.python.org/issue45

[issue46370] Move runtime static init to its own header file.

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

[issue46370] Move runtime static init to its own header file.

Eric Snow added the comment: New changeset bc02eac9d2cb36faffc5027b7ce09e6dd0922a7f by Eric Snow in branch 'main': bpo-46370: Move the static initializer for _PyRuntime to its own header file. (gh-30587) https://github.com/python/cpython/commit/bc02eac9d2cb36faffc5027b7ce09e6dd0922a7f

[issue46370] Move runtime static init to its own header file.

Change by Eric Snow : -- keywords: +patch pull_requests: +28785 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/30587 ___ Python tracker <https://bugs.python.org/issu

[issue46370] Move runtime static init to its own header file.

New submission from Eric Snow : The static initializer for `_PyRuntime` is currently defined in Include/internal/pycore_runtime.h. However, it is only needed by Python/pylifecycle.c (and Python/pystate.c for an optimization) and should only be used there. (Also, the initializer is quite

[issue46360] Inconsistent import behavior for (unusual) submodules

Eric Snow added the comment: > I'm going to assume the "even though sys.modules has `None`" case, > which I think is an oversight and should probably get fixed Yep, I agree. That's the case I was looking at in the first place. I noticed the other two as I was hacki

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

Eric Snow added the comment: > (*) I made the GC state per-interpreter: commit > 7247407c35330f3f6292f1d40606b7ba6afd5700 (Nov 20, 2019) FYI, this was done by me in an earlier comment which we ended up reverting. Later you basically un.reverted that. > The bug is that a C functi

  1   2   3   4   5   6   7   8   9   10   >