Mailman 3 January 2022 - Python-Dev

my plans for subinterpreters (and a per-interpreter GIL)
by Eric Snow 05 Jan '22

05 Jan '22

Hi all, I'm still hoping to land a per-interpreter GIL for 3.11. There is still a decent amount of work to be done but little of it will require solving any big problems: * pull remaining static globals into _PyRuntimeState and PyInterpreterState * minor updates to PEP 554 * finish up the last couple pieces of the PEP 554 implementation * maybe publish a companion PEP about per-interpreter GIL There are also a few decisions to be made. I'll open a couple of other threads to get feedback on those. Here I'd like your thoughts on the following: Do we need a PEP about per-interpreter GIL? I haven't thought there would be much value in such a PEP. There doesn't seem to be any decision that needs to be made. At best the PEP would be an explanation of the project, where: * the objective has gotten a lot of support (and we're working on addressing the concerns of the few objectors) * most of the required work is worth doing regardless (e.g. improve runtime init/fini, eliminate static globals) * the performance impact is likely to be a net improvement * it is fully backward compatible and the C-API is essentially unaffected So the value of a PEP would be in consolidating an explanation of the project into a single document. It seems like a poor fit for a PEP. (You might wonder, "what about PEP 554?" I purposefully avoided any discussion of the GIL in PEP 554. It's purpose is to expose subinterpreters to Python code.) However, perhaps I'm too close to it all. I'd like your thoughts on the matter. Thanks! -eric

14 29

Function Prototypes
by asleep.cult＠gmail.com 05 Jan '22

05 Jan '22

Hello In thread about PEP 677, I (with the help of another proposal) came up with an alternative to typing.Callable called function prototypes. The basic concept is to create a function prototype object when the body of a function is omitted. The thread can be found here: https://mail.python.org/archives/list/python-dev@python.org/thread/OGACYN2X… Mark Shannon initially proposed that functions be used as types and provided this example: @Callable def IntToIntFunc(a:int)->int: pass def flat_map( l: list[int], func: IntToIntFunc ) -> list[int]: .... I further proposed that we make the body of a function non-mandatory and create a function prototype if it is omitted. I provided these examples: import typing @typing.Callable def IntToIntFunc(a: int) -> int def flat_map( l: list[int], func: IntToIntFunc ) -> list[int]: ... import ctypes @ctypes.CFUNCTYPE def f(x: int) -> bool I have since taken it upon myself to implement this in a fork of cpython: https://github.com/asleep-cult/cpython To remain consistent with function definitions, I have also added an alternative lambda syntax that allows you to annotate arguments and the return type. The syntax requires you to parenthesize the argument list: lambda (a: int, b: int) -> int: ... This new lambda syntax also allows you to create a function prototype by omitting the body. The original example can be rewritten as follows: def flat_map( l: list[int], func: lambda (a: int) -> int ) -> list[int]: ... Problems: - It is not possible to use ParamSpec with this - The lambda prototype syntax might be jarring - Some people might accidentally forget the function body Here is some feedback that I have already collected: "Yeah, making the body optional (without looking at decorators) is not acceptable either. Too easy to do by mistake (I still do this All. The. Time. :-)" - Guido van Rossum "i would strongly prefer this over the existing pep" - Ronny Pfannschmidt "I find this unnecessary and unreadable. Python isn't C or Java." - BundleOfJoysticks (Reddit)

14 27

RFC on Callable Syntax PEP
by Steven Troxler 04 Jan '22

04 Jan '22

Hello all, Thanks everyone for comments on our earlier thread [1] about callable type syntax. We now have a draft PEP [2] proposing an arrow-based syntax for callable types, for example: ``` (int, str) -> bool # equivalent to Callable[[int, str], bool] ``` In support of the PEP we also have: - a reference implementation of the parser [3] to ensure the grammar is correct (tests [5], [6], [7]) - a detailed specification of planned runtime behavior [4], which is not yet in the reference implementation We'd like to get your feedback about the PEP in general, and especially details and edge cases we need to consider regarding runtime behavior. Cheers, Steven Troxler --------- [1] Earlier python-dev thread https://mail.python.org/archives/list/python-dev@python.org/thread/VBHJOS3L… [2] PEP 677: https://www.python.org/dev/peps/pep-0677/ [3] Reference implementation of Parser: https://github.com/stroxler/cpython/tree/callable-type-syntax--shorthand [4] Details on the runtime behavior: https://docs.google.com/document/d/15nmTDA_39Lo-EULQQwdwYx_Q1IYX4dD5WPnHbFG… [5] Ast tests for parser changes: https://github.com/stroxler/cpython/blob/20eb59fdca0d6d8dbe4efa3b04038c7c22… [6] Easy-read tests of examples from the PEP: https://github.com/stroxler/cpython/blob/callable-type-syntax--shorthand/Li… [7] Test sanity checking hundreds of examples pulled from typeshed: https://github.com/stroxler/cpython/blob/callable-type-syntax--shorthand/Li…

13 22