[issue46008] Prepare runtime/interp/thread state and init for upcoming changes.

Eric Snow added the comment: New changeset 32a67246b0d1e08cd50fc3bfa58052cfeb515b2e by Eric Snow in branch 'main': bpo-46008: Move Py*State init into distinct functions. (gh-29977) https://github.com/python/cpython/commit/32a67246b0d1e08cd50fc3bfa58052

[issue46008] Prepare runtime/interp/thread state and init for upcoming changes.

Eric Snow added the comment: At this point all the changes I was considering have been made, except for splitting type/object init into logical phases. That may or may not happen. Regardless, it can be done in a new issue. -- resolution: -> fixed stage: patch review -> re

[issue46008] Prepare runtime/interp/thread state and init for upcoming changes.

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

[issue46008] Prepare runtime/interp/thread state and init for upcoming changes.

Eric Snow added the comment: New changeset c8749b578324ad4089c8d014d9136bc42b065343 by Eric Snow in branch 'main': bpo-46008: Make runtime-global object/type lifecycle functions and state consistent. (gh-29998) https://github.com/python/cpyt

[issue32879] Race condition in multiprocessing Queue

Eric Meyer added the comment: The problem I was seeing ended up being improper GIL management in a c++ extension. It seems putting items that were created without the GIL on the queue causes a seg fault. -- ___ Python tracker <ht

[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

[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

[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

[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

[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

[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

[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

[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 __

[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

[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: 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

[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

[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

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: 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

[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:

[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: 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

[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

[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

[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

[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: 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

[issue37604] warnings should use a ContextVar to manage filters/registry

Eric Wieser added the comment: A relevant old issue is https://bugs.python.org/issue6647 -- components: +Library (Lib) nosy: +Eric Wieser type: -> behavior ___ Python tracker <https://bugs.python.org/issu

[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

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Eric Wieser added the comment: If the resolution here is that this is behaving as intended (which personally I disagree with), I think this issue should remain open as a documentation task - the docs should clearly state that this does not apply to PEP420 namespace packages

[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

[issue39471] Meaning and clarification of PyBuffer_Release()

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

[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:

[issue39610] memoryview.__len__ should raise an exception for 0d buffers

New submission from Eric Wieser : Right now, the behavior is: >>> import numpy as np >>> arr_0d = np.array(42) >>> mem_0d = memoryview(arr_0d) >>> len(mem_0d) 1 >>> mem_0d[0] TypeError: invalid indexing of 0-dim memory It seems bizarre to have this

[issue39610] memoryview.__len__ should raise an exception for 0d buffers

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

[issue39629] inspect.signature fails on math.hypot

New submission from Eric Fahlgren : Python 3.8's new math.hypot function also appears to suffer from the same issue as math.log: >>> import math, inspect >>> inspect.signature(math.hypot) Traceback (most recent call last): File "", line 1, in Fi

[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"

[issue39610] memoryview.__len__ should raise an exception for 0d buffers

Eric Wieser added the comment: Thanks for pointing out the docs reference, I updated the patch to reword that section. There's a sentence right before the one you draw attention to which to me reads as another argument to change this: > ``len(view)`` is equal to the length o

[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

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