[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

[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

[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

[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

[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

[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 (?)

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

New submission from Eric Snow : The docs page for the inspect module has a large table describing the special attributes of various important types. One entry for function attributes is missing: __module__. It should be added. Note that __module__ *is* included in the function attributes

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

Eric Snow added the comment: FWIW, I have some feedback on the PEP. (See msg357448.) Can we discuss here or should I open a mailing list thread? -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue36

[issue37292] _xxsubinterpreters: Can't unpickle objects defined in __main__

Eric Snow added the comment: In the meantime that leaves the workarounds that @crusaderky originally identified. You could also: * manually run __main__ in the subinterpreter first (sort of like multiprocessing does automatically); this works because the namespace of __main__ is not reset

[issue37292] _xxsubinterpreters: Can't unpickle objects defined in __main__

Eric Snow added the comment: Yeah, the case of pickle + __main__ is an awkward one. [1] However, the approach taken by multiprocessing isn't the right one for subinterpreters. Multiprocessing operates under 2 design points that do not apply to subinterpreters: * every process is ru

[issue36876] Global C variables are a problem.

Eric Snow added the comment: And I *am* still working on the c-analyzer + a test to that runs it, so we can keep from adding more globals. :) -- ___ Python tracker <https://bugs.python.org/issue36

[issue36876] Global C variables are a problem.

Eric Snow added the comment: FYI, others have been tackling this in separate issues (e.g. Victor, anyone relative to PEP 384). -- ___ Python tracker <https://bugs.python.org/issue36

[issue36876] Global C variables are a problem.

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

[issue37224] test__xxsubinterpreters fails randomly

Eric Snow added the comment: Thus far these are the failures we've seen: * not running when we expect it to be running: * interpreters.is_running(interp) * interpreters.run_string(interp, ...) * interpreters.destroy(interp) * can't find the interpreter even though we ex

[issue37224] test__xxsubinterpreters fails randomly

Eric Snow added the comment: BTW, Kyle, your problem-solving approach on this is on-track. Don't get discouraged. This stuff is tricky. :) -- ___ Python tracker <https://bugs.python.org/is

[issue37224] test__xxsubinterpreters fails randomly

Eric Snow added the comment: Sorry I haven't gotten back to you sooner, Kyle. Thanks for working on this. I'm looking at your PR right now. -- ___ Python tracker <https://bugs.python.o

[issue37224] test__xxsubinterpreters fails randomly

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

[issue38865] Can Py_Finalize() be called if the current interpreter is not the main interpreter?

Eric Snow added the comment: I could swear the topic of destroy-everything-in-PyFinalize has come up before but I don't remember anything specific. Doing so there sure makes sense though... -- ___ Python tracker <https://bugs.py

[issue38865] Can Py_Finalize() be called if the current interpreter is not the main interpreter?

Eric Snow added the comment: > * Is Python supposed to magically destroy the 3 interpreters? Doesn't it? Gah. I guess I was thinking of PyOS_AfterFork_Child(), which calls _PyInterpreterState_DeleteExceptMain(). :/ In September there was a nice comment right above Py_FinalizeEx(

[issue38865] Can Py_Finalize() be called if the current interpreter is not the main interpreter?

Eric Snow added the comment: tl;dr Py_Finalize() probably *should* only be allowed under the main interpreter. As you know well, when the runtime starts we do it at first relative to a partially initialized main interpreter and the finish initialization with a fully operational main

[issue30060] Crash with subinterpreters and Py_NewInterpreter()

Eric Snow added the comment: Victor's comment [1] on that related issue, implies that this may no longer be a problem (on 3.8). Please check. Thanks! [1] https://bugs.python.org/issue17978#msg355166 -- status: open -> pending __

[issue36854] GC operates out of global runtime state.

Eric Snow added the comment: Did I mention that you're my hero? :) -- ___ Python tracker <https://bugs.python.org/issue36854> ___ ___ Python-bugs-list m

[issue36854] GC operates out of global runtime state.

Eric Snow added the comment: Thanks so much for getting this done, Victor! > I'm not fully happy with this solution Should we have an issue open for finding a better solution? Are there risks with what you did that we don't w

[issue38650] Add constantness to PyStructSequence_UnnamedField

Eric Snow added the comment: I wouldn't worry about the c-analyzer stuff for now. I plan on re-generating the file in the near future. -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/is

[issue38778] Document that os.fork is not allowed in subinterpreters

Eric Snow added the comment: Flipping the label one more time did the trick. Thanks again, Phil! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue38816] Clarify about fork() and the CPython runtime in the C-API docs.

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

[issue38816] Clarify about fork() and the CPython runtime in the C-API docs.

New submission from Eric Snow : The C-API docs are a bit sparse on the interplay between C fork() and the CPython runtime. -- assignee: eric.snow components: Documentation messages: 356705 nosy: eric.snow, gregory.p.smith, pconnell priority: normal pull_requests: 16684 severity

[issue38778] Document that os.fork is not allowed in subinterpreters

Eric Snow added the comment: Nice work, Phil. We need a backport to 3.8, but the miss-islington bot is having trouble with it. [1] Either we can try flipping the "needs backport to 3.8" label again or you could create a backport PR yourself (like miss-islington suggested). If y

[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals

Eric Snow added the comment: It depends on how you look at the degree to which you are interacting with the runtime. This is a fairly low-level hook into the runtime. So arguably if you are using this API then you should specify being a "core" extension. That said, getting t

[issue38631] Replace Py_FatalError() with regular Python exceptions

Eric Snow added the comment: FWIW, I agree. :) -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue38631> ___ ___ Python-bugs-list mailin

[issue36876] Global C variables are a problem.

Eric Snow added the comment: New changeset e4c431ecf50def40eb93c3969c1e4eeaf7bf32f1 by Eric Snow in branch 'master': bpo-36876: Re-organize the c-analyzer tool code. (gh-16841) https://github.com/python/cpython/commit/e4c431ecf50def40eb93c3969c1e4e

[issue36876] Global C variables are a problem.

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

[issue38187] test.test_tools.test_c_analyzer fails in refleak mode

Change by Eric Snow : -- status: pending -> closed ___ Python tracker <https://bugs.python.org/issue38187> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue38187] test.test_tools.test_c_analyzer fails in refleak mode

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

[issue38187] test.test_tools.test_c_analyzer fails in refleak mode

Eric Snow added the comment: New changeset 6693f730e0eb77d9453f73a3da33b78a97e996ee by Eric Snow in branch 'master': bpo-38187: Fix a refleak in Tools/c-analyzer. (gh-16304) https://github.com/python/cpython/commit/6693f730e0eb77d9453f73a3da33b7

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

Eric Snow added the comment: +1 to the suggested "whatsnew" updates. If no one beats me to it I'll work on a PR soon. -- ___ Python tracker <https://bugs.pyt

[issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent()

Eric Snow added the comment: I've re-opened this issue to address the original point: documenting PyThreadState_DeleteCurrent(). FWIW, I don't see a problem with documenting it if we're keeping it around (which it looks like we are). We will address reverting GH-

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

Eric Snow added the comment: @Joannah, sounds good. Thanks! -- ___ Python tracker <https://bugs.python.org/issue38266> ___ ___ Python-bugs-list mailin

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

Eric Snow added the comment: I *was* going to suggest that we also put an underscore prefix on the name, but I couldn't think of a reason why we would want to discourage use (other than to reduce the size of the [supported] public API). Moving it to Include/cpython/pystate.h is pro

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

Eric Snow added the comment: s/un-revert/revert/ -- ___ Python tracker <https://bugs.python.org/issue38266> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

Eric Snow added the comment: FWIW, when we un-revert we should be sure to move PyThreadState_DeleteCurrent() from Include/pystate.h to Include/cpython/pystate.h. (I suppose that could be done in a separate PR to keep the git history clear

[issue38266] Revert bpo-37878: Make PyThreadState_DeleteCurrent() Internal

Eric Snow added the comment: FWIW, I support reverting the removal of PyThreadState_DeleteCurrent(). We only reverted under the assumption that no one was using this function. Clearly we were mistaken. :) I'll re-open #37878 to revive the discussion about documenting the function (

[issue38187] test.test_tools.test_c_analyzer fails in refleak mode

Change by Eric Snow : -- pull_requests: +15890 pull_request: https://github.com/python/cpython/pull/16304 ___ Python tracker <https://bugs.python.org/issue38

[issue38005] Coercing strings and non-integer numbers to interpreter ID and channel ID

Eric Snow added the comment: Yeah, dropping str support is fine. It wouldn't be hard to add it back in if later we find it's useful. :) -- ___ Python tracker <https://bugs.python.o

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

New submission from Eric Snow : A "PyInterpreterState *interp" field on PyTypeObject would allow us to quickly access the originating interpreter from any object. This will help us avoid more costly lookups. The additional pointer used for this should not have a significant imp

[issue38141] Use fewer statics in Argument Clinic.

Eric Snow added the comment: That might work. :) There are two key problems under subinterpreters that do not share the GIL: * races on refcount operations * cache thrashing due to refcount operations (under multi-core threads) A lock would certainly mitigate the first problem. I'

[issue36876] Global C variables are a problem.

Eric Snow added the comment: New changeset 088b63ea7a8331a3e34bc93c3b873c60354b4fad by Eric Snow in branch 'master': bpo-36876: Fix the globals checker tool. (gh-16058) https://github.com/python/cpython/commit/088b63ea7a8331a3e34bc93c3b873c

[issue38141] Use less statics in Argument Clinic.

New submission from Eric Snow : (This is a sub-task of bpo-36876, "Global C variables are a problem.".) Currently Argument Clinic generates "_PyArg_Parser _parser" as a static variable. Dropping "static" solves the problem of thread safety (e.g. for subin

[issue36876] Global C variables are a problem.

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

[issue36876] Global C variables are a problem.

Eric Snow added the comment: New changeset 64535fc6c0712caef0bc46be30e661f7ccf8280e by Eric Snow in branch 'master': bpo-36876: Skip test_check_c_globals for now. (gh-16017) https://github.com/python/cpython/commit/64535fc6c0712caef0bc46be30e661

[issue36876] Global C variables are a problem.

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

[issue36876] Global C variables are a problem.

Eric Snow added the comment: @db3l, I'll take a look right away. -- ___ Python tracker <https://bugs.python.org/issue36876> ___ ___ Python-bugs-list m

[issue36876] Global C variables are a problem.

Eric Snow added the comment: New changeset ee536b2020b1f0baad1286dbd4345e13870324af by Eric Snow in branch 'master': bpo-36876: Add a tool that identifies unsupported global C variables. (#15877) https://github.com/python/cpython/commit/ee536b2020b1f0baad1286dbd4345e

[issue38113] Remove statics from ast.c

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

[issue38113] Remove statics from ast.c

Eric Snow added the comment: New changeset ac46eb4ad6662cf6d771b20d8963658b2186c48c by Eric Snow (Dino Viehland) in branch 'master': bpo-38113: Update the Python-ast.c generator to PEP384 (gh-15957) https://github.com/python/cpython/commit/ac46eb4ad6662cf6d771b20d896365

[issue35381] posixmodule: convert statically allocated types (DirEntryType & ScandirIteratorType) to heap-allocated types

Eric Snow added the comment: @Jeroen, see Dino's expalantion in https://bugs.python.org/issue38075#msg351627 (relative to the "random" module). -- ___ Python tracker <https://bugs.pyt

[issue38091] Import deadlock detection causes deadlock

Change by Eric Snow : -- nosy: +brett.cannon, eric.snow ___ Python tracker <https://bugs.python.org/issue38091> ___ ___ Python-bugs-list mailing list Unsub

[issue37872] Move _Py_IDENTIFIER statics in Python/import.c to top of the file

Eric Snow added the comment: Yeah, I'm fine with dropping this. In the file we have some global and some local, so my suggestion was to consolidate a little. However, it mostly doesn't matter. :) -- resolution: -> rejected stage: needs patch -> resolved status

[issue37888] Sub-interpreters : Confusing docs about state after calling Py_NewInterpreter()

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

[issue12128] Allow an abc.abstractproperty to be overridden by an instance data attribute

Eric Snow added the comment: I'm guessing it should have been https://mail.python.org/pipermail/python-list/2011-May/604497.html. -- ___ Python tracker <https://bugs.python.org/is

[issue38091] Import deadlock detection causes deadlock

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

[issue36876] Global C variables are a problem.

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

[issue36876] Global C variables are a problem.

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

[issue19820] docs are missing info about module attributes

Eric Snow added the comment: The relevant module attributes are described in the importlib docs: https://docs.python.org/3/library/importlib.html#importlib.abc.Loader.load_module -- versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.3, Python 3.4

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

Eric Snow added the comment: New changeset 375f35be0688da0fc0f27afc4faea76590d7c24d by Eric Snow (Miss Islington (bot)) in branch '3.8': bpo-36487: Make C-API docs clear about what the main interpreter is. (gh-15080) https://github.com/python/cpyt

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

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

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

Eric Snow added the comment: New changeset 854d0a4b98b13629252e21edaf2b785b429e5135 by Eric Snow (Joannah Nanjekye) in branch 'master': bpo-36487: Make C-API docs clear about what the main interpreter is. (gh-12666) https://github.com/python/cpyt

[issue37312] Remove deprecated _dummy_thread and dummy_threading modules

Eric Snow added the comment: FTR, Antoine originally removed in b43c4caf81b10e5c7ebaeb3a712c6db584f60bbd and added back (but deprecated) a few days later in b43c4caf81b10e5c7ebaeb3a712c6db584f60bbd. [1] That happened in September 2017 for Python 3.7. [1] https://bugs.python.org

[issue37496] Support annotations in signature strings.

Eric Snow added the comment: +1 on using a string for Parameter.annotation and Signature.return_annotation. -- ___ Python tracker <https://bugs.python.org/issue37

[issue35476] _imp_create_dynamic_impl() does not clear error.

Eric Snow added the comment: Hmm, looks like this was already fixed by Serhiy (for bpo-35454) the day before I opened this issue. :) 3.8/master: GH-11077 8905fcc85a6fc3ac394bc89b0bbf40897e9497a6 3.7: GH-11105 62674f3a36ec55f86a5f20ee028a37fbd549bd6c 3.6: GH-11106

[issue35476] _imp_create_dynamic_impl() does not clear error.

Eric Snow added the comment: Sorry, @Batuhan. We appreciate your effort and would be glad to see more contributions from you. I hope you at least learned something positive while working on this. :) -- ___ Python tracker <ht

[issue37284] Not obvious that new required attrs of sys.implementation must have a PEP.

Eric Snow added the comment: @potomak, thanks for doing this! -- ___ Python tracker <https://bugs.python.org/issue37284> ___ ___ Python-bugs-list mailin

[issue37284] Not obvious that new required attrs of sys.implementation must have a PEP.

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

[issue37574] Mention spec_from_loader() in Finder.find_spec() docs.

New submission from Eric Snow : When writing an importer, the finder (either MetaPathFinder or PathEntryFinder) must implement `find_spec()`. A useful tool for that is the existing `spec_from_loader()`. [1] The docs for `MetaPathFinder.find_spec()` and `PathEntryFinder.find_spec()` should

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

Eric Snow added the comment: Note that there has been a little discussion of this in the past, particularly around the time that argument clinic was introduced: https://bugs.python.org/issue23967#msg241140. -- ___ Python tracker <ht

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

New submission from Eric Snow : In early 2014 (3.3), when argument clinic was added, we added support for turning func.__text_signature__ into an inspect.Signature object. However, the functionality to convert a string into a Signature was never exposed publicly. Here's a patch to

[issue37496] Support annotations in signature strings.

New submission from Eric Snow : In early 2014 (3.3), when argument clinic was added, we added support for turning func.__text_signature__ into an inspect.Signature object. However, at that time we did not add support for annotations (see the nested "parse_name()" in _signatu

[issue37416] If threading is not imported from the main thread it sees the wrong thread as the main thread.

Eric Snow added the comment: FWIW, this might also have implications for thread shutdown during runtime/interpreter finalization. -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue37

[issue37416] If threading is not imported from the main thread it sees the wrong thread as the main thread.

Eric Snow added the comment: Note that in Python 3.7 we consolidated a bunch of the global runtime state. The "main_thread" static in ceval.c moved to the internal struct _PyRuntimestate and in 3.7 it is accessible as _Runtime.ceval.pending.main_thread (but only if you

[issue37376] pprint for types.SimpleNamespace

Eric Snow added the comment: Thanks, Carl Bordum Hansen! -- nosy: +eric.snow resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue37293] concurrent.futures.InterpreterPoolExecutor

Eric Snow added the comment: @Davin, we've spoken before about something similar for multiprocessing, IIRC. :) -- nosy: +davin ___ Python tracker <https://bugs.python.org/is

[issue37293] concurrent.futures.InterpreterPoolExecutor

Eric Snow added the comment: FWIW, performance benefits when subinterpreters stop sharing the GIL are not the only benefit. In fact, PEP 554 is specifically written to avoid that consideration, focusing on the benefits of the concurrency model (i.e. CSP). So I wouldn't call this poin

[issue37316] mmap.mmap() passes the wrong variable to PySys_Audit()

Change by Eric Snow : -- nosy: +steve.dower ___ Python tracker <https://bugs.python.org/issue37316> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23892] Introduce sys.implementation.opt_levels

Eric Snow added the comment: There are (solvable) problems with my original recommendation: 1. sys.implementation is by definition not suitable for third-party import hooks to modify + it is set during the Python implementation during runtime init + it is effectively read-only after that

[issue23892] Introduce sys.implementation.opt_levels

Eric Snow added the comment: (Sorry for taking so long!) Thanks for doing this, Cheryl! I'm leaving a review on your PR. :) Also, in PEP 421 it says that you need a PEP for this. [1] "Such a PEP need not be long, just long enough." (I just realized that the requirement is

[issue37284] Not obvious that new required attrs of sys.implementation must have a PEP.

New submission from Eric Snow : PEP 421 added sys.implementation for Python implementors to provide values required by stdlib code (e.g. importlib). That PEP indicates that any new required attributes must go through the PEP process. [1] That requirement isn't obvious. To fix th

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