Mailman 3 May 2021 - Python-Dev

March Steering Council update.
by Thomas Wouters June 7, 2021

June 7, 2021

The SC has just published the community update for March: https://github.com/python/steering-council/blob/main/updates/2021-03-steeri… We're still trying to get these done every month, but between the rush of PEPs and other issues before the 3.10b1 deadline, and PyCon US, we're delayed a little. (The April update hopefully won't be too long.) In the meantime, the SC keynote from PyCon US covers our longer-term plans and our points of view on a few other subjects, and that will hopefully be up on YouTube ( https://www.youtube.com/playlist?list=PL2Uw4_HvXqvYk1Y5P8kryoyd83L_0Uk5K) soon. (Since it's mentioned in the notes below, I just want to point out that we didn't record on April 19th; it was pushed back to May 3rd, the same day 3.10b1 was cut.) March 1 - Steering Council synced up on the rejection draft for PEP 651. Group discussed the importance of conveying that all aspects of the proposal were reviewed and the decision is a holistic one. Group will continue working on the draft and will sync up via Slack during the week so it can be sent out. - The Steering Council discussed PEP 648. Barry created a doc and the group will consolidate feedback+questions into this document. Then the Steering Council will post this on Discourse as well as to python-dev@. - The Steering Council extensively discussed PEP 637. The group decided that it would reject the PEP based on the PEPs costs not being worth the benefits. - The Steering Council also discussed typing in general and who should own it. - Next week the SC will vote on the Documentation Work Group's charter. <https://github.com/python/steering-council/blob/main/updates/2021-03-steeri…>March 8 - The Steering Council discussed Mark's response to the rejection of PEP 651. - The group also discussed the notification for PEP 637. - The group approved PEP 624 & PEP 597. - The Steering Council discussed PEP 644 and decided further communication was needed with Christian. - The Steering Council voted on and approved the Documentation Work Group. - The group discussed moving master to main and decided it needed to be done. The SC discussed communication around this change. <https://github.com/python/steering-council/blob/main/updates/2021-03-steeri…>March 15 - Thomas updated the notifications for PEP 597, PEP 624 and PEP 637, and sent out the notifications March 15th. - Group checked in on the draft for PEP 648. Thomas has more text to add to it. - The Steering Council discussed what kind of presentation they will give at PyCon US. The group decided on a combination of presentation and Q&A. Team is working on an outline. SC members were also reminded to register for PyCon US, and encourage others to do so. - Barry proposed to the SC that they create a Work Group with a subset of the Python Security Response Team members and that group can help scope the future of the PSRT group. Everyone is fine with this. - Steering Council discussed code of conduct situations around changing master to main. The group decided on a warning to S.D. that will be sent as a warning to all. Thomas is working on the initial draft. <https://github.com/python/steering-council/blob/main/updates/2021-03-steeri…>March 22 - Barry and Thomas checked-in on PEP 648's draft response, they will be sending it out soon. - The SC reviewed PEP 644 more. Pablo raised a concern around users that can be in an env without OpenSSL 1.1.1 or newer and then not being able to use wheels. Pablo will email Christian to get clarification and will keep the SC informed. - Steering Council discussed their keynote at PyCon US 2021. They would like to gather questions from the community. Ewa will create a Slido, which will be live from April 5 to 11th. SC will review questions on the 12th. The current plan is to record on April 19th. - Steering Council discussed the response to Debian. Carol's done with her draft. Pablo is going to take a look at it to see if anything else needs to be added. - SC discussed the behavior on python-dev@ pertaining to switching git from master to main. <https://github.com/python/steering-council/blob/main/updates/2021-03-steeri…>March 29 - The Steering Council accepted PEP 644 (Require OpenSSL 1.1.1 or newer) - SC accepted PEP 652 (Maintaining the Stable ABI) - SC checked in on the draft response for PEP 648 (Extensible customizations of the interpreter at startup), and the draft response to the Debian discussion. - SC met with Ezio, PM for the GitHub Issues migration, to talk about status, progress and next steps, including keeping python-dev up to date. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

4 5

GDB not breaking at the right place
by Skip Montanaro June 7, 2021

June 7, 2021

I'm having a hard time debugging some virtual machine code because GDB won't break where it's supposed to. Here's my breakpoint #2: 2 breakpoint keep y 0x00005555556914fd ceval_reg.h:_PyEval_EvalFrameDefault:TARGET_JUMP_IF_FALSE_REG breakpoint already hit 1 time p/x oparg p (oparg >> 16) & 0xff | (oparg >> 8) & 0xff p oparg & 0xff p *fastlocals@4 but when it breaks, it's not at the beginning of the case (that is, where the TARGET_JUMP_IF_FALSE_REG label is defined), but inside the SETLOCAL macro of the COMPAR_OP_REG case! (That is, it's not anywhere close to the correct place.) case TARGET(COMPARE_OP_REG): { int dst = REGARG4(oparg); int src1 = REGARG3(oparg); int src2 = REGARG2(oparg); int cmpop = REGARG1(oparg); assert(cmpop <= Py_GE); PyObject *left = GETLOCAL(src1); PyObject *right = GETLOCAL(src2); PyObject *res = PyObject_RichCompare(left, right, cmpop); *SETLOCAL(dst, res);* if (res == NULL) goto error; DISPATCH(); } It actually breaks in the Py_XDECREF which is part of the SETLOCAL macro: #define SETLOCAL(i, value) do { PyObject *tmp = GETLOCAL(i); \ GETLOCAL(i) = value; \ *Py_XDECREF(tmp)*; } while (0) (actually, in the Py_DECREF underneath the Py_XDECREF macro). I've configured like so: ./configure --with-pydebug --with-tracerefs --with-assertions Python/ceval.c is compiled with this GCC command: gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I. -I./Include -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c I don't know if this is a GCC problem, a GDB problem, or a Skip problem. Is there more I can do to help the tool chain break at the correct place? It seems that if I break at a hard line number, GDB does the right thing, but I'd kind of prefer to use the symbolic label instead. I rather like the notion of breaking at a label name, but if GCC/GDB can't figure things out, I guess I'll have to live with line numbers. Thanks, Skip

7 17

name for new Enum decorator
by Ethan Furman June 6, 2021

June 6, 2021

Greetings! The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements into a decorator instead, and I'm having a hard time thinking up a name. What is the behavior? Well, a name in a flag type can be either canonical (it represents one thing), or aliased (it represents two or more things). To use Color as an example: class Color(Flag): RED = 1 # 0001 GREEN = 2 # 0010 BLUE = 4 # 0100 PURPLE = RED | BLUE # 0101 WHITE = RED | GREEN | BLUE # 0111 The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE are aliases for certain flag combinations. But what if we have something like: class Color(Flag): RED = 1 # 0001 BLUE = 4 # 0100 WHITE = 7 # 0111 As you see, WHITE is an "alias" for a value that does not exist in the Flag (0010, or 2). That seems like it's probably an error. But what about this? class FlagWithMasks(IntFlag): DEFAULT = 0x0 FIRST_MASK = 0xF FIRST_ROUND = 0x0 FIRST_CEIL = 0x1 FIRST_TRUNC = 0x2 SECOND_MASK = 0xF0 SECOND_RECALC = 0x00 SECOND_NO_RECALC = 0x10 THIRD_MASK = 0xF00 THIRD_DISCARD = 0x000 THIRD_KEEP = 0x100 Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are aliasing values that don't exist, but it seems intentional and not an error. So, like the enum.unique decorator that can be used when duplicate names should be an error, I'm adding a new decorator to verify that a Flag has no missing aliased values that can be used when the programmer thinks it's appropriate... but I have no idea what to call it. Any nominations? -- ~Ethan~

13 18

Need help to debug a ssl crash on Windows which prevents merging PRs
by Victor Stinner June 1, 2021

June 1, 2021

Hi, In the 3.10 branch, it became really hard to merge PRs because the following ssl crashs on Windows: https://bugs.python.org/issue44252 It has a failure rate 1/2 (on average) on the "Windows x86" and "Windows x64" jobs of GitHub Action and on the Win32 and Win64 jobs of the Azure Pipelines. I failed to reproduce it on an up to date Windows 10 with an up to date Visual Studio 2019. I cannot say if it's a race condition, if it's a bug in Python, if it's a bug in the tests (it sounds unlikely, it worked well previously and it's a hard crash, not a Python exception), if it's a bug in the C compiler or in Windows itself... Since there are other random test failures like test_asyncio, it now requires multiple "re-run jobs" on GitHub Actions. Example of test_asyncio test which fails frequently on Windows: https://bugs.python.org/issue41682 If someone can reproduce https://bugs.python.org/issue44252 crash on Windows, can you please provide me a SSH access to your machine so I can debug it? Here is my public SSH key: https://github.com/vstinner.keys Is there a way to get a SSH access to a machine of the GitHub Action CI job or of an Azure Pipelines CI job? Victor -- Night gathers, and now my watch begins. It shall not end until my death.

2 2

Re: The repr of a sentinel
by Eric Nieuwland June 1, 2021

June 1, 2021

To add to the suggestions already given in this thread I dug into code I wrote some time ago. Offered as an inspiration. === missing.py === from typing import Any def MISSING(klass: Any) -> Any: """ create a sentinel to indicate a missing instance of a class :param klass: the class of which an instance is missing :return: missing class object """ g = globals() missing_klass_name = f"_MISSING_{klass.__module__}_{klass.__name__}_MISSING_" if missing_klass_name not in g: g[missing_klass_name] = type( missing_klass_name, (klass,), { "__repr__": lambda x: f"MISSING({klass.__name__})", } ) return g[missing_klass_name]() === and as a demo: === demo_missing.py === import pickle from missing import MISSING x = MISSING(str) y = "bar" print(f"{x!r} == {y!r}: {x == y}") print(f"{x!r} is {y!r}: {x is y}") # MISSING(str) == 'bar': False # MISSING(str) is 'bar': False with open("object.pickled", "wb") as f: pickle.dump(x, f) with open("object.pickled", "rb") as f: y = pickle.load(f) print(f"{x!r} == {y!r}: {x == y}") print(f"{x!r} is {y!r}: {x is y}") # MISSING(str) == MISSING(str): True # MISSING(str) is MISSING(str): False def foo(a: int = MISSING(int), b: int = MISSING(int)): print(f"{a=} {isinstance(a, int)}") print(f"{b=} {isinstance(b, int)}") print(f"{a!r} == {b!r}: {a == b}") print(f"{a!r} is {b!r}: {a is b}") foo() # a=MISSING(int) True # b=MISSING(int) True # MISSING(int) == MISSING(int): True # MISSING(int) is MISSING(int): False foo(1) # a=1 True # b=MISSING(int) True # 1 == MISSING(int): False # 1 is MISSING(int): False class Test: ... t = MISSING(Test) print(f"{t=}") # t=MISSING(Test) ===

2 1

The repr of a sentinel
by Irit Katriel June 1, 2021

June 1, 2021

Following a recent change, we now have in traceback.py: _sentinel = object() def print_exception(exc, /, value=_sentinel, tb=_sentinel, limit=None, file=None, chain=True): So now: >>> import traceback >>> help(traceback.print_exception) Help on function print_exception in module traceback: print_exception(exc, /, value=<object object at 0x000002825DF09650>, tb=<object object at 0x000002825DF09650>, limit=None, file=None, chain=True) Is there a convention on how such default sentinel values should appear in docs? https://bugs.python.org/issue43024

22 66

Farewell, for now :)
by Kyle Stanley May 31, 2021

May 31, 2021

Hi all, Last week, I started a new thread on discuss.python.org <https://discuss.python.org/t/farewell-for-now/8918?u=aeros> about my intention to take a further extended break from open source to continue my mental health healing process. Just wanted to announce it in the other channels as well since I know that not everyone has the bandwidth to keep up with more than just the MLs. In the thread, I discussed my intention to pursue the path of becoming a Buddhist monk for some time, and recently detailed my adventures at a local Thai temple. Check it out if you are interested. :) With Loving Regards, -- --Kyle R. Stanley, Python Core Developer (what is a core dev? <https://devguide.python.org/coredev/>) *Pronouns: they/them **(why is my pronoun here?* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…> )

1 0

python-iterators mailing list on SourceForge
by Julien Palard May 31, 2021

May 31, 2021

Hi, PEP 234 mention https://sourceforge.net/p/python/mailman/python-iterators/ but the project mailing list archives are marked as "hidden". Looks like projects admin and developers can get the "hidden link", but I think it would be nice to "unhide" the archives if someone is still admin there and if it's possible, to "unbreak" the link from the PEP. Bests, -- [Julien Palard](https://mdk.fr)

6 14

Help with the grail browser
by Prakhar Sehgal May 30, 2021

May 30, 2021

The latest version of Grail is 0.6 which was released in 1999 was made for Python 1 but I want to make one compatible with Python 3. But I need help for that. Currently me and Guido van Rossum are working on this. Any help will be welcomed. This is the link for the GitHub repo: https://github.com/PrakharPythonProgrammer/Grail-0.6 Sincerely Prakhar

2 1

Implementing async enumerate
by Filipe Alves Caixeta May 30, 2021

May 30, 2021

Hello, Python 3.10 comes with the built-in *anext()* but I think we may be missing some other equivalent built-in functions like *list* and *enumerate*. I didn't discuss the idea of creating a PEP for this but I would like to get some help with the implementation. The equivalent Python code would be *async def aenumerate(sequence, start=0): n = start async for elem in sequence: yield n, elem n += 1* The code for enumerate if here https://github.com/python/cpython/blob/2f3a87856c7033227577b9ed0c77ed753114… The *next* function creates a tuple and return with (n, elem) *result = PyTuple_New(2);PyTuple_SET_ITEM(result, 0, next_index);PyTuple_SET_ITEM(result, 1, next_item);return result;* For the async implementation I would have to instead return an *async_generator_asend* object and that would resolve to the tuple. Calling *tp_as_async->am_anext* and getting the value doesn't seem like the solution because I should not get the result at this stage yet. I would like to have a hint on how to implement this =D

3 2