[issue30475] Docs for PyDict_GetItemWithError() should say it returns a borrowed reference.

Changes by Eric Snow : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue30535] Warn that meta_path is not empty

Changes by Eric Snow : -- keywords: +easy ___ Python tracker <http://bugs.python.org/issue30535> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29514] Add a test case that prevents magic number changes in minor releases

Eric Snow added the comment: Sorry I didn't see the just-landed PR earlier, but it may make sense to not skip that test under *any* release level for a micro version > 0: @unittest.skipUnless( (sys.version_info.micro > 0 or sys.version_info.releaselevel

[issue30547] [Windows] SubinterpreterTest.test_callbacks_leak() of test_atexit leaks references

Eric Snow added the comment: Thanks for taking care of this, Victor, Stéphane & Louie! -- ___ Python tracker <http://bugs.python.org/issue30547> ___ ___ Python

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

Eric Snow added the comment: New changeset be3b295838547bba267eb08434b418ef0df87ee0 by Eric Snow in branch 'master': bpo-35886: Make PyInterpreterState an opaque type in the public API. (GH-11731) https://github.com/python/cpython/commit/be3b295838547bba267eb08434b418

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

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

[issue35724] Check for main interpreter when checking for "main" thread (for signal handling)

Change by Eric Snow : -- pull_requests: -11124 ___ Python tracker <https://bugs.python.org/issue35724> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35724] Check for main interpreter when checking for "main" thread (for signal handling)

Eric Snow added the comment: New changeset 64d6cc826dacebc2493b1bb5e8cb97828eb76f81 by Eric Snow in branch 'master': bpo-35724: Explicitly require the main interpreter for signal-handling. (GH-11530) https://github.com/python/cpython/commit/64d6cc826dacebc2493b1bb5e8cb97

[issue35724] Check for main interpreter when checking for "main" thread (for signal handling)

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

[issue36097] Use only public C-API in _xxsubinterpreters module.

New submission from Eric Snow : After discussions about our use of the public C-API in stdlib extension modules, I realized that I'd written the _xxsubinterpreters module using internal C-API. However, there's no reason not to stick to the public C-API. Fixing this will requir

[issue36097] Use only public C-API in _xxsubinterpreters module.

Change by Eric Snow : -- keywords: +patch pull_requests: +12034 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: New changeset ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 by Eric Snow in branch 'master': bpo-33608: Factor out a private, per-interpreter _Py_AddPendingCall(). (GH-11617) https://github.com/python/cpython/commit/ef4ac967e2f3a9a18330cc6abe14ad

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by Eric Snow : -- pull_requests: +12057 ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: GH-11617 has introduces a slight performance regression which will need to be resolved. If I can't find the problem right away then I'll probably temporarily revert the commit. See https://mail.python.org/pipermail/python-dev/2019-February/1

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

Eric Snow added the comment: @Armin, thanks for fixing things on your end so quickly. :) Adding PyInterpreterState.dict and a public getter function (a la PyThreadState) is probably fine. I'm just not sure how that relates to the problem with cffi's use of the "builtins

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

Eric Snow added the comment: On Mon, Feb 25, 2019 at 3:02 AM STINNER Victor wrote: > But that's where I suggested to test "popular C extensions" with a C API > change before merging it. It's ok if issues are discovered later, but the > author of backward inco

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: At least, it *might* be a performance regression. Here are the two commits I tried: after: ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 (PR #11617, from this issue) before: 463572c8beb59fd9d6850440af48a5c5f4c0c0c9 (the one right before) After building each (a

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: Here's what I did (more or less): $ python3 -m pip install --user perf $ python3 -m perf system tune $ git clone g...@github.com:python/performance.git $ git clone g...@github.com:python/cpython.git $ cd cpython $ git che

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: ...so it doesn't appear that my PR introduces a performance regression. -- ___ Python tracker <https://bugs.python.org/is

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: FYI, I have a couple of small follow-up changes to land before I close this issue. -- ___ Python tracker <https://bugs.python.org/issue33

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: +1 from me @Armin, thanks to Nick I understand your request better now. I'll put up a PR by the end of the week if no one beats me to it. -- nosy: +arigo, eric.snow ___ Python tracker <https://bugs.py

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by Eric Snow : -- pull_requests: +12086 ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36157] Document PyInterpreterState_Main().

New submission from Eric Snow : PyInterpreterState_Main() is a function in the public C-API that returns a pointer to the main interpreter's state. The main interpreter is the first one created by the CPython runtime during startup (e.g. when the "python" command is run). Do

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: New changeset b05b711a2cef6c6c381e01069dedac372e0b9fb2 by Eric Snow in branch 'master': bpo-33608: Use _Py_AddPendingCall() in _PyCrossInterpreterData_Release(). (gh-12024) https://github.com/python/cpython/commit/b05b711a2cef6c6c381e01069dedac

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: Thinking about this, what is the key difference with the existing PyModule_GetState() function? Is it just the return type (module-defined void * vs. a regular dict)? Certainly it provides a C-only namespace that all extensions can share (like

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: New changeset bda918bf65a88560ec453aaba0758a9c0d49b449 by Eric Snow in branch 'master': bpo-33608: Simplify ceval's DISPATCH by hoisting eval_breaker ahead of time. (gh-12062) https://github.com/python/cpython/commit/bda918bf65a88560ec453aaba

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: I've merged the PR for hoisting eval_breaker before the ceval loop starts. @Raymond, see if that addresses the performance regression you've been seeing. I'll close this issue after I've sorted out the buildbot issues David mentioned (on

[issue36124] Provide convenient C API for storing per-interpreter state

Change by Eric Snow : -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue36124> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36124] Provide convenient C API for storing per-interpreter state

Change by Eric Snow : -- keywords: +patch pull_requests: +12135 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue36124] Provide convenient C API for storing per-interpreter state

Change by Eric Snow : -- assignee: -> eric.snow ___ Python tracker <https://bugs.python.org/issue36124> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue36097] Use only public C-API in _xxsubinterpreters module.

Eric Snow added the comment: New changeset bcfa450f210074e16feb761ae5b3e966a2532fcf by Eric Snow in branch 'master': bpo-36097: Use only public C-API in the_xxsubinterpreters module (adding as necessary). (#12003) https://github.com/python/cpyt

[issue36097] Use only public C-API in _xxsubinterpreters module.

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

[issue35466] Use a linked list for the ceval pending calls.

Eric Snow added the comment: At this point I'm not terribly interested in this. :) -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.pyth

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: That's okay, Victor. Thanks for jumping on this. I'll take a look when I get a chance. -- ___ Python tracker <https://bugs.python.o

[issue36097] Use only public C-API in _xxsubinterpreters module.

Eric Snow added the comment: I'll re-merge this once this problem in issue #33608 is resolved. -- resolution: fixed -> stage: resolved -> status: closed -> open ___ Python tracker <https://bugs.pyth

[issue36097] Use only public C-API in _xxsubinterpreters module.

Eric Snow added the comment: Actually, this is independent of that change. It had to be reverted because the PR was based on the earlier PR from #33608. So I may merge this separately...or not, since it would mean having to sort out merge conflicts. :) -- stage: -> needs pa

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: Thanks for taking a look Victor! That info is helpful. It will likely be a few days before I can sort this out. Once I have addressed the problem I'll re-merge. I plan on using the "buildbot-custom" branch to make sure the buildbots are happy

[issue36177] test_io: test_daemon_threads_shutdown_stdout_deadlock() fails on x86 Windows7 3.x

Eric Snow added the comment: This is resolved with gh-12159, no? -- ___ Python tracker <https://bugs.python.org/issue36177> ___ ___ Python-bugs-list mailin

[issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD CURRENT Shared 3.x

Eric Snow added the comment: This is resolved with gh-12159, no? -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue36114> ___ ___ Python-bug

[issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x

Eric Snow added the comment: This is resolved with gh-12159, no? -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue36116> ___ ___ Python-bug

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: On Sat, Mar 2, 2019 at 12:33 AM Armin Rigo wrote: > PyModule_GetState() requires having the module object that corresponds > to the given interpreter state. I'm not sure how a C extension module is > supposed to get its own module object corres

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: Also, while PyThreadState_GetDict() is the inspiration here, we don't have to copy it exactly. For instance, PyInterpreterState_GetDict() takes a PyInterpreterState* argument, whereas PyThreadState_GetDict() takes no arguments and gets the PyThreadState*

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by Eric Snow : -- pull_requests: +12228 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mai

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by Eric Snow : -- pull_requests: +12231 ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by Eric Snow : -- pull_requests: +12234 ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by Eric Snow : -- pull_requests: +12235 ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by Eric Snow : -- pull_requests: +12236 ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: New changeset 5be45a6105d656c551adeee7770afdc3b806fbb5 by Eric Snow in branch 'master': bpo-33608: Minor cleanup related to pending calls. (gh-12247) https://github.com/python/cpython/commit/5be45a6105d656c551adeee7770afd

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: New changeset 8479a3426eb7d1840473f7788e639954363ed37e by Eric Snow in branch 'master': bpo-33608: Make sure locks in the runtime are properly re-created. (gh-12245) https://github.com/python/cpython/commit/8479a3426eb7d1840473f7788e6399

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: New changeset 842a2f07f2f08a935ef470bfdaeef40f87490cfc by Eric Snow in branch 'master': bpo-33608: Deal with pending calls relative to runtime shutdown. (gh-12246) https://github.com/python/cpython/commit/842a2f07f2f08a935ef470bfdaeef4

[issue36097] Use only public C-API in _xxsubinterpreters module.

Change by Eric Snow : -- pull_requests: +12326 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue36097> ___ ___ Python-

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by Eric Snow : -- pull_requests: +12327 ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36097] Use only public C-API in _xxsubinterpreters module.

Eric Snow added the comment: New changeset c11183cdcff6af13c4339fdcce84ab63f7930ddc by Eric Snow in branch 'master': bpo-36097: Use only public C-API in the_xxsubinterpreters module (adding as necessary). (gh-12359) https://github.com/python/cpyt

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: New changeset d2fdd1fedf6b9dc785cf5025b548a989faed089a by Eric Snow in branch 'master': bpo-36124: Add PyInterpreterState.dict. (gh-12132) https://github.com/python/cpython/commit/d2fdd1fedf6b9dc785cf5025b548a9

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: @arigo, thanks for nudging us here. :) Let me know if there's anything else that would help here. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python t

[issue32312] Create Py_AtExitRegister C API

Eric Snow added the comment: > Neil Schemenauer added the comment: > Regarding m_traverse, maybe the list of finalizers should be stored somewhere > in the interpreter > state, not in the atexit module state. That would make more sense to me. > atexit could merely be >

[issue36450] 3D Array Assignment to all 2D sub-arrays

Eric Snow added the comment: In Python, multiplication on a list does not make copies of the values in the original list. So what you have done is equivalent to the following: a = [0, 0] b = [a, a] M = [b, b] Hence: >>> M[0] is M[1] True >>> M[0][0] is M[0][1

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: As Inada-san indicated, the problem might be resolved already. So without the option of reproducing the problem, it will be hard to resolve this. Here's some information you could provide that might help narrow down the scope a bit: * what (stdlib/third-

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: Also: * are any of your threads daemon threads? -- ___ Python tracker <https://bugs.python.org/issue36469> ___ ___ Python-bug

[issue30703] Non-reentrant signal handler (test_multiprocessing_forkserver hangs)

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

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: * Are any signals (or signal handlers) involved? * Are you monkeypatching any builtins, builtin/stdlib modules (or any parts of those)? Keep in mind that a number of bugs have been fixed in later releases related to the various things I've asked about.

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: At this point I think it's likely that the problem relates to how daemon threads are handled during runtime finalization. What normally happens in the main thread of the "python3" executable is this: 1. Python runtime initializes 2. main interpre

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: Here are some things that would likely help: * in the main thread stop your daemon threads if you hit SystemExit * make sure daemon threads release/acquire the GIL frequently (so they notice finalization) * make sure daemon threads otherwise exit promptly (no

[issue36475] PyEval_AcquireLock() and PyEval_AcquireThread() do not handle runtime finalization properly.

New submission from Eric Snow : Daemon threads keep running until they finish or until finalization starts. For the latter, there is a check right after the thread acquires the GIL which causes the thread to exit if runtime finalization has started. [1] However, there are functions in the

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: I've opened issue36475 for the two C-API functions that do not cause daemon threads to exit. -- ___ Python tracker <https://bugs.python.org/is

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: Looking at the stack traces for all your threads (super helpful, BTW), I saw 4 groups: * (1) main thread (blocked on GIL during runtime finalization) + Thread 1 * (12) blocked on GIL in call to PyEval_RestoreThread() (socket, select, time.sleep(), file.read

[issue36475] PyEval_AcquireLock() and PyEval_AcquireThread() do not handle runtime finalization properly.

Change by Eric Snow : -- components: +Interpreter Core ___ Python tracker <https://bugs.python.org/issue36475> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36476] Runtime finalization assumes all other threads have exited.

New submission from Eric Snow : Among the first 3 things that happen in Py_FinalizeEx() are, in order: 1. wait for all non-daemon threads (of the main interpreter) to finish 2. call registered atexit funcs 3. mark the runtime as finalizing At that point the only remaining Python threads are

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: I've also opened issues #36476 and #36477. -- ___ Python tracker <https://bugs.python.org/issue36469> ___ ___ Python-bugs-l

[issue36477] Subinterpreters are not finalized during runtime finalization.

New submission from Eric Snow : When using subinterpreters, any that exist when Py_FinalizeEx() is called do not appear to get cleaned up during runtime finalization. Maybe I've been looking at the code too much and I'm missing something. :) This really isn't a problem excep

[issue36476] Runtime finalization assumes all other threads have exited.

Eric Snow added the comment: FYI, I've opened issue36477 to deal with the subinterpreters case. -- ___ Python tracker <https://bugs.python.org/is

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: @Remy, aside from the recommendations I've made, I'm not sure what else we can do to help. Before we close the issue, I'd really like to ensure that one of those threads is holding the GIL still. It would definitely be a problem if a thread exi

[issue36477] Subinterpreters are not finalized during runtime finalization.

Change by Eric Snow : -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Lingering subinterpreters should be implicitly cleared on shutdown ___ Python tracker <https://bugs.python

[issue36225] Lingering subinterpreters should be implicitly cleared on shutdown

Eric Snow added the comment: Interestingly, I noticed this independently today. :) Here's what I wrote in #36477 (which I've closed as a duplicate): When using subinterpreters, any that exist when Py_FinalizeEx() is called do not appear to get cleaned up during runtime finalizati

[issue36225] Lingering subinterpreters should be implicitly cleared on shutdown

Eric Snow added the comment: test__xxsubinterpreters is a great place for tests that exercise use of subinterpreters, including most lifecycle operations. There are also one or two subinterpreter-related tests in test_embed. However, for this issue the interplay with runtime finalization

[issue36097] Use only public C-API in _xxsubinterpreters module.

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

[issue36157] Document PyInterpreterState_Main().

Eric Snow added the comment: As I noted on the PR, this might be a good chance to make sure the C-API docs are clear about what the "main" interpreter is. -- ___ Python tracker <https://bugs.python.o

[issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure can terminate the calling thread

Eric Snow added the comment: Related: * #36475: "PyEval_AcquireLock() and PyEval_AcquireThread() do not handle runtime finalization properly." * #36476: "Runtime finalization assumes all other threads have exited." -- ___ Py

[issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure can terminate the calling thread

Eric Snow added the comment: > > if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) > > _Py_IsFinalizing() check is redundant :-) Not really: * _Py_IsFinalizing() checks if the runtime is finalizing * _Py_CURRENTLY_FINALIZING checks if the current threa

[issue36479] Exit threads when interpreter is finalizing rather than runtime.

New submission from Eric Snow : Currently when a thread acquires the GIL, it subsequently exits if the runtime is finalizing. This helps with some cases like with stopping daemon threads. This behavior should instead be triggered by the thread's interpreter finalizing rather tha

[issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure can terminate the calling thread

Eric Snow added the comment: > Currently PyEval_RestoreThread and its callers (mainly PyGILState_Ensure) > can terminate the thread if the interpreter is finalizing: s/interpreter/runtime/ Most likely (guaranteed?) it will be in the main interpreter, but it is actually not trigge

[issue33356] Windows 10 buildbot: test__xxsubinterpreters.test_already_running() fails randomly

Eric Snow added the comment: I'll take a look when I get a chance. -- ___ Python tracker <https://bugs.python.org/issue33356> ___ ___ Python-bugs-list m

[issue36487] Make C-API docs clear about what the "main" interpreter is

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

[issue36157] Document PyInterpreterState_Main().

Eric Snow added the comment: Thanks for working on this, Joannah! :) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue36487] Make C-API docs clear about what the "main" interpreter is

Eric Snow added the comment: I should have added something like this earlier, but here are key points to consider covering: * "main" interpreter is the original, created when the runtime initializes * historically almost always the only Python interpreter in a process * this i

[issue32280] Expose `_PyRuntime` through a section name

Change by Eric Snow : -- versions: +Python 3.8 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue32280> ___ ___ Python-bugs-list mailing list Unsub

[issue19476] Add a dedicated specification for module "reloading" to the language reference

Eric Snow added the comment: Thanks for checking in, Cheryl! Clearly no one picked up this banner. :) Furthermore, I'm not aware of any reload-related complaints coming from the community. I know of only a couple major use cases for reload(): refresh parts of a running app d

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: New changeset f13c5c8b9401a9dc19e95d8b420ee100ac022208 by Eric Snow in branch 'master': bpo-33608: Factor out a private, per-interpreter _Py_AddPendingCall(). (gh-12360) https://github.com/python/cpython/commit/f13c5c8b9401a9dc19e95d8b420ee1

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: Thanks for checking, Victor. Don't feel bad about your results, nor about not checking sooner. :) We'll get this sorted out. For now I'll revert. This is not code that changes very often, so there isn't much benefit to keeping it merged

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by Eric Snow : -- pull_requests: +12733 ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: New changeset b75b1a3504a0cea6fac6ecba44c10b2629577025 by Eric Snow in branch 'master': bpo-33608: Revert "Factor out a private, per-interpreter _Py_AddPendingCall()." (gh-12806) https://github.com/python/cpython/commit/b75b1a3504a0cea6fac6

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Eric Snow added the comment: @Victor, I set up a FreeBSD 12.0 VM (in Hyper-v) and made sure core files were getting generated for segfaults. Then I cloned the cpython repo, built it (using GCC), and ran regrtest as you recommended. It generated no core files after half an hour. I

[issue31954] Don't prevent dict optimization by coupling with OrderedDict

Eric Snow added the comment: Please don't miss the fact that the main reason for mirroring the dict table is to get O(1) node lookup (in the linked list). Otherwise most lookup-dependent operations, like __delitem__(), would become O(n); whereas in the pure-Python implementation they

[issue36666] threading.Thread should have way to catch an exception thrown within

Eric Snow added the comment: Here's a basic decorator along those lines, similar to one that I've used on occasion: def as_thread(target): def _target(): try: t.result = target() except Exception as exc: t.fai

[issue36710] Pass _PyRuntimeState as an argument rather than using the _PyRuntime global variable

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

[issue36737] Warnings operate out of global runtime state.

New submission from Eric Snow : (See Include/internal/pycore_warnings.h and Python/_warnings.c.) The warnings module's state (filters, default action, etc.) is currently stored at the level of the global runtime. That's a problem for the following reasons: * Python objects a

[issue36710] Pass _PyRuntimeState as an argument rather than using the _PyRuntime global variable

Eric Snow added the comment: FWIW, PEP 554 is part of a larger project that I've been working on (slowly) for several years now. [1] The concrete objective is to leverage subinterpreters as the mechanism by which we can achieve multi-core parallelism in Python code. Moving the GIL

[issue36710] Pass _PyRuntimeState as an argument rather than using the _PyRuntime global variable

Eric Snow added the comment: I don't think this change is the right way to go (yet), but something related might be. First, let's be clear on the status quo for CPython. (This has gotten long, but I want to be clear.) Status Quo For simplicity sake, let's say

[issue36710] Pass _PyRuntimeState as an argument rather than using the _PyRuntime global variable

Eric Snow added the comment: FWIW, I don't mean to side-track this issue. If we want to have any further discussion about broader solutions then let's take this to capi-sig. In fact, I've started a thread there. I'd post the link, but I think it got

[issue36737] Warnings operate out of global runtime state.

Eric Snow added the comment: Good point. Also, the whole idea of inheriting things (settings, some copied objects, etc.) into subinterpreters is interesting. My initial reaction is that folks would appreciate that feature, at least for a handful of things. It's not critical, but is

<    6   7   8   9   10   11   12   13   14   15   >