As I’m reading through several Python Enhancement Proposal (PEP) documents, I have to keep in mind that I don’t have to understand everything on my first read through. And I also have to keep a goal in mind so I don’t get too distracted. For this session, the motivation was copy/pasting “async with” from example code without having any idea what those keywords meant. PEP 380 was the last in my list of self-assigned prerequisite readings, but now it’s time for the main attraction: PEP 492 Coroutines with async and await syntax. After completing this study session, I have a much better understanding of what “async with” does.

It was interesting to follow Python evolution on this front. My prerequisite PEP reading all discussed generators and coroutines as a specific type of generator. In PEP 492 they laid out the reasons for separating out coroutines as its own concept. The underlying implementation of coroutines still uses many pieces of generator infrastructure, but the language will now treat them as different things. As part of this evolution, a large part of this document discussed is devoted to “Design Considerations” of alternative approaches, and “Transition Plan” for maintaining compatibility with pre-492 coroutine syntax.

One decision I found disappointing was that debugging features are disabled by default. I understand the motivation to ensure debugging features do not impact production code, but I think leaving them out completely is going too far. Beginners who most need feedback from Python runtime are not going to know they need to set an OS environment variable PYTHONASYNCIODEBUG.

But I am in full support of another decision: there’s no comprehension shorthand:

Syntax for asynchronous comprehensions could be provided, but this construct is outside of the scope of this PEP.

I don’t like Python comprehension shorthands and I’m glad there to see this PEP did not add one. It’s possible this text meant only exactly what it says, but in my professional career I’ve used “out of scope” as a polite rephrase of “I don’t like this idea and I’m not doing it.” It made me smile to think the PEP author might be doing the same here.

Reading through PEP 492 concludes this particular study session, and the knowledge informed updated goals for my MX340 CircuitPython project.