[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules

Eric Snow added the comment: Exactly. :) I'd expect PEP 499 to specify changing __module__ of classes and functions from __main__ to the module name (__spec__.name). This aligns closely with the whole point of the PEP. :) As a bonus, it will simplify things for pickling (which do

[issue1021318] PyThreadState_Next not thread safe

Eric Snow added the comment: On Wed, Dec 11, 2019 at 7:02 AM STINNER Victor wrote: > We may have to fix this API first, and clarify the scope of the different > locks. +1 -- ___ Python tracker <https://bugs.python.org/iss

[issue38962] Reference leaks in subinterpreters

Eric Snow added the comment: Thanks for all the work on this! -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue38962> ___ ___ Python-bug

[issue36854] GC operates out of global runtime state.

Eric Snow added the comment: On Wed, Dec 4, 2019 at 4:36 AM STINNER Victor wrote: > Each time I tried to fix a bug in the Python finalization, I introduced worse > bugs :-D :) > We cannot fix all bugs at once, we have to work incrementally. +1 > I like the idea of introducing

[issue38858] new_interpreter() should reuse more Py_InitializeFromConfig() code

Eric Snow added the comment: Thanks for working on this. It really does have far-reaching benefits, not just for the subinterpreter stuff I'm interested in. :) -- ___ Python tracker <https://bugs.python.org/is

[issue37776] Test Py_Finalize() from a subinterpreter

Eric Snow added the comment: On Fri, Dec 13, 2019 at 11:22 AM Lewis Gaul wrote: > So it looks like adding a specific testcase for this is likely to weed out an > actual issue here! +1 -- ___ Python tracker <https://bugs.python.org/i

[issue37224] test__xxsubinterpreters fails randomly

Eric Snow added the comment: On Sat, Nov 30, 2019 at 9:23 PM Kyle Stanley wrote: > Based on the above hint, I was able to make some progress on a potential > solution. Thanks Eric. That's great! > Instead of only checking "frame->f_executing", I changed "_is

[issue37224] test__xxsubinterpreters fails randomly

Eric Snow added the comment: On Sat, Nov 30, 2019 at 9:23 PM Kyle Stanley wrote: > I have a few ideas that I'd like to test out for fixing this failure, and if > any of them produce positive results I'll report back. Sounds good. > Since the failures are still consis

[issue39042] Use the runtime's main thread ID in the threading module.

New submission from Eric Snow : The threading module has a "main_thread()" function that returns a Thread instance for the "main" thread. The main thread is the one running when the runtime is initialized and has a specific role in various parts of the runtime. Cur

[issue38904] "signal only works in main thread" in main thread

Eric Snow added the comment: Before 3.8, the "signal" module checked against the thread in which the module was initially loaded, treating that thread as the "main" thread. That same was true (and still is) for the "threading" module. The problem for bo

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

Eric Snow added the comment: Sorry for the delay, Phil. I'll try to take a look in the next couple of hours. -- ___ Python tracker <https://bugs.python.org/is

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

Eric Snow added the comment: I'm out of time and this deserves some careful discussion. I'll get to it next Friday (or sooner if possible). Sorry! -- ___ Python tracker <https://bugs.python.o

[issue37224] test__xxsubinterpreters fails randomly

Eric Snow added the comment: On Fri, Dec 13, 2019 at 8:08 PM Kyle Stanley wrote: > Yeah, I named it "_PyInterpreterIsFinalizing" and it's within > Include/cpython. Definitely open > to suggestions on the name though, it's basically just a private getter for

[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

New submission from Eric Snow : types.SimpleNamespace was added in 3.3 (for use in sys.implementation; see PEP 421), which predates the change to preserving insertion order in dict. At the time we chose to sort the attributes in the repr, both for ease of reading and for a consistent output

[issue39058] argparse should preserve argument ordering in Namespace

Eric Snow added the comment: > Currently, Namespace() objects sort the attributes in the __repr__. This is > annoying because argument > order matters and because everywhere else in the module we preserve order > (i.e. users see help in the > order that arguments are adde

[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

Change by Eric Snow : -- stage: -> needs patch ___ Python tracker <https://bugs.python.org/issue39075> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue39076] Use types.SimpleNamespace for argparse.Namespace

New submission from Eric Snow : types.SimpleNamespace does pretty much exactly the same thing as argparse.Namespace. We should have the latter subclass the former. I expect the only reason that wasn't done before is because SimpleNamespace is newer. The only thing argparse.Namespace

[issue39058] argparse should preserve argument ordering in Namespace

Eric Snow added the comment: FWIW, I've also opened issue #39076 about subclassing types.SimpleNamespace. -- ___ Python tracker <https://bugs.python.org/is

[issue39042] Use the runtime's main thread ID in the threading module.

Eric Snow added the comment: Hmm, I wonder if this should be considered a regression in 3.8. As demonstrated in issue38904, the following code changed behavior as of 3.8, under certain conditions: import signal import threading def int_handler(): ... if threading.current_thread

[issue38904] "signal only works in main thread" in main thread

Eric Snow added the comment: So resolving issue39042 would be enough, particularly if we backported the change to 3.8? -- ___ Python tracker <https://bugs.python.org/issue38

[issue39110] It seems that list() changes the value of the parameter

Eric Snow added the comment: Your problem is with UserList. This is from the implementation: def __getitem__(self, i): if isinstance(i, slice): return self.__class__(self.data[i]) else: return self.data[i] So each slice is creating a new Tree

[issue39042] Use the runtime's main thread ID in the threading module.

Eric Snow added the comment: I don't see a reason not to consider this is a regression. The only problem with the fix would be for any users that rely on the inaccurate reporting of the threading module. Considering that possibly includes only some embedders (and folks using _thread m

[issue38918] Add __module__ entry for function type in inspect docs table.

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

[issue1596321] KeyError at exit after 'import threading' in other thread

Eric Snow added the comment: related: issue #39042 "Use the runtime's main thread ID in the threading module." -- nosy: +eric.snow ___ Python tracker <https://bugs.pytho

[issue1332869] Fatal Python error: Interpreter not initialized

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

[issue28812] Deadlock between GIL and pystate head_mutex.

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

[issue14073] allow per-thread atexit()

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

[issue31517] MainThread association logic is fragile

Eric Snow added the comment: probably a duplicate: issue #39042 "Use the runtime's main thread ID in the threading module." -- ___ Python tracker <https://bugs.pyt

[issue34296] Speed up python startup by pre-warming the vm

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

[issue13077] Unclear behavior of daemon threads on main thread exit

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

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

Eric Snow added the comment: Adding to the list: * any OS threads created by an extension module or embedding application -- ___ Python tracker <https://bugs.python.org/issue36

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

Change by Eric Snow : -- stage: -> needs patch versions: +Python 3.9 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue36476> ___ ___ Python-

[issue24770] Py_Finalize() doesn't stop daemon threads

Eric Snow added the comment: I'm closing this in favor of #36476 "Runtime finalization assumes all other threads have exited." -- nosy: +eric.snow resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Runtime finalization ass

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

Eric Snow added the comment: Problems with lingering threads during/after runtime finalization continue to be a problem. I'm going to use this issue as the focal point for efforts to resolve this. Related issues: * #36479 "Exit threads when interpreter is finalizing rather th

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

Change by Eric Snow : -- nosy: +pconnell ___ Python tracker <https://bugs.python.org/issue36476> ___ ___ 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: Thanks for the detailed analysis, Phil. I think the results are pretty conclusive: daemon threads are the worst. :) But seriously, thanks. As you demonstrated, it isn't just Python "daemon" threads that cause the problem. It is essentially any

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

Eric Snow added the comment: Analysis by @pconnell: * https://bugs.python.org/issue33608#msg357169 * https://bugs.python.org/issue33608#msg357170 * https://bugs.python.org/issue33608#msg357179 tl;dr daemon threads and external C-API access during/after runtime finalization are causing

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

Eric Snow added the comment: To put it another way: (from issue33608#msg358748) > The docs [1] aren't super clear about it, but there are some fundamental > assumptions we make about runtime finalization: > > * no use of the C-API while Py_FinalizeEx() is executing (e

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

Eric Snow added the comment: So I see 3 things to address here: 1. Python daemon threads 2. Python threads created in atexit handlers 3. non-Python threads accessing the C-API Possible solutions (starting point for discussion): 1. stop them at the point we stop waiting for non-daemon

[issue37340] remove free_list for bound method objects

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

[issue26219] implement per-opcode cache in ceval

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

[issue39076] Use types.SimpleNamespace for argparse.Namespace

Eric Snow added the comment: Sorry if there was any confusion. I didn't mean to suggest we get rid of argparse.Namespace (in favor of SimpleNamespace). Rather, the former would subclass the latter. > * types.SimpleNamespace() sorts attributes, so this would get in the way of > i

[issue39076] Use types.SimpleNamespace for argparse.Namespace

Eric Snow added the comment: Anyway, this probably isn't a discussion worth extending much further. I don't think it's important enough. :) So if you have reservations about this then feel free to close the issue. -- ___ Python

[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

Eric Snow added the comment: > IMHO, dropping the sort should be a default behavior. If some user need > this feature, maybe we could supply a param to open the sort function or not? Consider opening a separate issue (or start a thread on python-ideas) about adding a more sophist

[issue37224] test__xxsubinterpreters fails randomly

Eric Snow added the comment: On Wed, Jan 15, 2020 at 12:20 AM Kyle Stanley wrote: > As can be seen from the results above, the interpreter is not even running in > the first place before > it's destroyed, so of course destroy() won't raise an RuntimeError. I think

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

Eric Snow added the comment: Thanks, Victor! -- ___ Python tracker <https://bugs.python.org/issue36710> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39376] Avoid modifying the process global environment (not thread safe)

Eric Snow added the comment: +1 This has impact on subinterpreters once they stop sharing the GIL. (It's already on my list of global resources that need better protection.) -- nosy: +eric.snow ___ Python tracker <https://bugs.py

[issue39443] Inhomogeneous behaviour for descriptors in between the class-instance and metaclass-class pairs

Eric Snow added the comment: First of all, thanks for asking about this. Everything is working as expected. Let's look at why. First, be sure the behavior of descriptors is clear: the descriptor protocol is only triggered by "dotted access" on an object ("obj.at

[issue39443] Inhomogeneous behaviour for descriptors in between the class-instance and metaclass-class pairs

Eric Snow added the comment: @Raymond, What do you think about adding a helpful note or two in the docs? -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue39

[issue39395] The os module should unset() environment variable at exit

Eric Snow added the comment: FTR, #39376 is related (avoid the process-global env vars in the first place). -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue39

[issue38076] Make struct module PEP-384 compatible

Eric Snow added the comment: > there's still probably some underlying issue in multiprocessing. Whoa, I've never heard that before! -- ___ Python tracker <https://bugs.pytho

[issue15600] expose the finder details used by the FileFinder path hook

Eric Snow added the comment: I have many other things higher on my todo list. :) I'll re-open this issue if I get back to the project that motivated this (i.e. "source translation via import hooks for filename suffix"). -- resolution: -> out of date stage: patch

[issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code

Eric Snow added the comment: FTR: As Martin noted in #19514, there isn't any performance difference for statics, whether local or global. For static locals the compiler (at least on linux) generates symbols named as ".<#>" and they are treated as global. One key

[issue39516] ++ does not throw a SyntaxError

Eric Snow added the comment: FWIW, this is the sort of thing that is usually best suited to be reported by linters, not the Python runtime. -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue39

[issue37224] test__xxsubinterpreters fails randomly

Eric Snow added the comment: Thanks, Kyle. That helps at least a little. :) -- ___ Python tracker <https://bugs.python.org/issue37224> ___ ___ Python-bug

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Eric Snow added the comment: On Sun, Feb 2, 2020 at 2:53 PM Raymond Hettinger wrote: > Is the sub-interpreter PEP approved? PEP 554 is not approved yet (and certainly is not guaranteed, though I'm hopeful). However, that PEP is exclusively about exposing subinterpreters in th

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Eric Snow added the comment: On Sun, Feb 2, 2020 at 3:32 PM Raymond Hettinger wrote: > Random idea (not carefully thought-out): Would it be simpler to have these > objects just > ignore their refcount by having dealloc() be a null operation or having it > set the refcount

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Eric Snow added the comment: > This is pretty much one of the two approaches I have been considering. The other approach is to leave the current static singletons alone and only use them for the main interpreter. Each subinterpreter would get its own copy, created when that interpreter

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

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

[issue17422] language reference should specify restrictions on class namespace

Eric Snow added the comment: Thanks for working on this. Sorry I didn't get a chance to see your PR sooner. There was one small thing that needs to be changed back, as I implied in my comment on the PR [1]. Please undo the change in the text from "ordered mapping"

[issue33234] Improve list() pre-sizing for inputs with known lengths

Eric Snow added the comment: Possible backward incompatibility caused by this issue: issue39829 -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue33

[issue39879] Update language reference to specify that dict is insertion-ordered.

New submission from Eric Snow : As of 3.7 [1], dict is guaranteed to preserve insertion order: the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec. However, at least one key part of the language reference [2] was

[issue17422] language reference should specify restrictions on class namespace

Eric Snow added the comment: Thanks for fixing that, Caleb! FWIW, I've opened a separate issue (#39879) for adding a note in the language reference about dict ordering. Sorry for the confusion. -- resolution: -> fixed stage: patch review -> resolved status: ope

[issue37497] Add inspect.Signature.from_text().

Eric Snow added the comment: Honestly, I don't recall exactly the concrete use case for which I opened this. :) I *think* it was related to applying a more restrictive signature onto an existing function (e.g. with a decorator). -- ___ P

[issue39829] __len__ called twice in the list() constructor

Eric Snow added the comment: FWIW, I encouraged Kim to file this. Thanks Kim! While it isn't part of any specification, it is an unexpected change in behavior that led to some test failures. So I figured it would be worth bringing up. :) I did find it surprising that we were not ca

[issue39829] __len__ called twice in the list() constructor

Eric Snow added the comment: I'm not opposed. :) I just don't want to impose on your time. -- assignee: -> pablogsal resolution: not a bug -> stage: resolved -> status: closed -> open ___ Python tracker <https://b

[issue39984] Move pending calls from _PyRuntime to PyInterpreterState

Eric Snow added the comment: Awesome! Thanks for doing this, Victor. I'll take a look when I can and adjust the changes for bpo-33608. If you'll recall, I made a similar change as part of the solution for that issue, which we later reverted due to problems we discovered w

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

Eric Snow added the comment: FYI, in bpo-39984 Victor moved pending calls to PyInterpreterState, which was part of my reverted change. However, there are a few other pieces of that change that need to be applied before this issue is resolved. I'm not sure when I'll get

[issue40077] Convert static types to PyType_FromSpec()

Eric Snow added the comment: > Wouldn't having less static types slow down startup time? FWIW, I've been considering an approach where the main interpreter keeps using static types but subinterpreters use heap types. If it isn't too much effort (or too hacky) then it mig

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

Eric Snow added the comment: > I close this issue with a complex history. > > If someone wants to continue to work on this topic, please open an issue with > a very clear description of what should be done and how it is supposed to be > used. Yeah, there is more to do. I&

[issue40234] Disallow daemon threads in subinterpreters optionally.

New submission from Eric Snow : In bpo-37266 we strictly disallowed creation of daemon threads in subinterpreters. However, this is backward-incompatible for existing users of the subinterpreter C-API (such as mod-wsgi). Rather than reverting that change I suggest that we make it opt-in

[issue37266] Daemon threads must be forbidden in subinterpreters

Eric Snow added the comment: I've opened bpo-40234 to address backward incompatibility from this change (e.g. affecting mod-wsgi). -- ___ Python tracker <https://bugs.python.org/is

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

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

[issue32604] Expose the subinterpreters C-API in Python for testing use.

Change by Eric Snow : -- pull_requests: +19088 pull_request: https://github.com/python/cpython/pull/19768 ___ Python tracker <https://bugs.python.org/issue32

[issue40390] Implement _xxsubinterpreters.channel_send_wait().

Eric Snow added the comment: Thanks, Ben. I'll take a look. -- components: +Library (Lib) -C API title: Implement a C API for channel_send_wait for subinterpreters. -> Implement _xxsubinterpreters.channel_send_wait(). ___ Python tracker

[issue32604] Expose the subinterpreters C-API in Python for testing use.

Change by Eric Snow : -- pull_requests: +19090 pull_request: https://github.com/python/cpython/pull/19770 ___ Python tracker <https://bugs.python.org/issue32

[issue32604] Expose the subinterpreters C-API in Python for testing use.

Change by Eric Snow : -- pull_requests: +19149 pull_request: https://github.com/python/cpython/pull/19829 ___ Python tracker <https://bugs.python.org/issue32

[issue40453] Add PyConfig._isolated_interpreter: isolated subinterpreters

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

[issue40417] PyImport_ReloadModule emits deprecation warning

Eric Snow added the comment: Yeah, that looks like an oversight. I've approved your PR. Thanks! -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/is

[issue40417] PyImport_ReloadModule emits deprecation warning

Eric Snow added the comment: Did you have a need for this to be fixed in 3.8 or earlier? This seems reasonably and simple enough to backport. I suppose someone could be relying on an implicit import of the "imp" module, but that seems highly unlikely and susp

[issue40350] modulefinder chokes on numpy - dereferencing None in spec.loader

Change by Eric Snow : -- stage: -> test needed versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue40350> ___ ___ Python-bugs-list mai

[issue40350] modulefinder chokes on numpy - dereferencing None in spec.loader

Eric Snow added the comment: Ah, namespace packages. :) Yeah, the code is not taking the "spec.loader is None" case into account. I expect the fix would be to add handling of that case a few lines up in the code, right after handling BuiltinImporter and FrozenImporter. Offha

[issue40390] Implement _xxsubinterpreters.channel_send_wait().

Eric Snow added the comment: Thanks for working on this, Ben! FWIW, I've put up a separate PR to demonstrate how I was thinking we would solve this: https://github.com/python/cpython/pull/19829. -- ___ Python tracker <https://bugs.py

[issue38880] Subinterpreters: List interpreters associated with a channel end

Eric Snow added the comment: Thanks again, Lewis! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue40513] Move _PyRuntimeState.ceval to PyInterpreterState

Eric Snow added the comment: FWIW, I think it would make sense to keep "signals_pending" under _PyRuntimeState rather than moving it to PyInterpreterState. Signals are only handled by the main interpreter (in its main thread). Even though "signals_pending" is useful to

[issue40513] Move _PyRuntimeState.ceval to PyInterpreterState

Eric Snow added the comment: >From a user perspective, does it make sense to have a different >recursion_limit per interpreter? I don't see a problem with it. However, >does it make sense to also keep a global value that we default to when a >per-interpreter value is not

[issue40513] Move _PyRuntimeState.ceval to PyInterpreterState

Eric Snow added the comment: If this issue covers the GIL (which it seems to) then I'd expect _PyRuntimeState.gilstate to be handled here too. -- ___ Python tracker <https://bugs.python.org/is

[issue40010] Inefficient signal handling in multithreaded applications

Eric Snow added the comment: Good catch on this, Victor. Thanks for doing it. -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue40

[issue40514] Add --experimental-isolated-subinterpreters build option

Eric Snow added the comment: It would probably make sense to remove the build option in the 3.9 release. We can leave it in master, but remove it in the 3.9 branch once it has been created. -- ___ Python tracker <https://bugs.python.

[issue40058] Running test_datetime twice fails with: module 'datetime' has no attribute '_divide_and_round'

Eric Snow added the comment: FYI, with the following additions in Lib/test/test_datetime.py... before = set(sys.modules) try: pure_tests = import_fresh_module(TESTS, fresh=['datetime', '_strptime'], blocked=['_datet

[issue40533] Subinterpreters: don't share Python objects between interpreters

Eric Snow added the comment: Yep, before per-interpreter GIL is official we must get to the point where *no* PyObject objects are shared. Making PyObject.ob_refcnt atomic until then (only as part of the experiment) should be fine. -- ___ Python

[issue32604] Expose the subinterpreters C-API in Python for testing use.

Eric Snow added the comment: New changeset a1d9e0accd33af1d8e90fc48b34c13d7b07dcf57 by Eric Snow in branch 'master': bpo-32604: [_xxsubinterpreters] Propagate exceptions. (GH-19768) https://github.com/python/cpython/commit/a1d9e0accd33af1d8e90fc48b34c13

[issue40572] Support basic asynchronous cross-interpreter operations.

New submission from Eric Snow : (This is a continuation of the work from bpo-33608. That issue ended up with a lot of baggage and clutter (due to problems that have since been resolved), so we closed it. This issue is where we're picking it up fresh.) When two interpreters are cooper

[issue40572] Support basic asynchronous cross-interpreter operations.

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

[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

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

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

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

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

Eric Snow added the comment: New changeset 7ec59d8861ef1104c3028678b2cacde4c5693e19 by Eric Snow in branch 'master': bpo-36876: [c-analyzer tool] Add a "capi" subcommand to the c-analyzer tool. (gh-23918) https://github.com/python/cpython/commit/7ec59d8861ef1104c302

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

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

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

Eric Snow added the comment: New changeset 5ae9be68d9f1a628fdc920b647257f94afb77887 by Eric Snow in branch 'master': bpo-36876: [c-analyzer tool] Additional CLI updates for "capi" command. (gh-23929) https://github.com/python/cpython/commit/5ae9be68d9f1a628fdc9

[issue32604] [subinterpreters] PEP 554 implementation: add interpreters module

Change by Eric Snow : -- pull_requests: +20105 pull_request: https://github.com/python/cpython/pull/20926 ___ Python tracker <https://bugs.python.org/issue32

<    2   3   4   5   6   7   8   9   10   11   >