What can we do before 3.10 beta and the public announcement?

[markshannon]

3.10 beta is in 5 weeks (3rd May). The language summit is a week later.

What can we do in that time?
We don't want to:

• Make very large a changes. Large changes just before beta aren't going to make Pablo happy.
• Bring too much attention to what we are doing.

I'm working on:
#33
#34
which are reasonably sized changes.

Any other suggestions?

We could just work on bigger features in feature branches, with the intention to merge them after beta.

[gvanrossum]

I can work on some super-instructions.

[markshannon]

I've been looking through my many experiments. I've found a few things worth doing that are not too disruptive:

• (#37) Offset cell variables from the base of locals. This is easy to do in the compiler and simplifies the interpreter.
• (#38) Add some bytecodes to generators/co-routines to handle all the corner case code in gen.send(). Callers should not need to check the internal state of the generator, the generator bytecode should handle it.
• (#39) Split YIELD_FROM into two. Having two bytecodes allows us to more easily tell whether an exception caused by throw should be passed into sub-generators or not. Again, the caller should not need to know about the internal state of the generator/coroutine.

[ericsnowcurrently]

• Offset cell variables from the base of locals. This is easy to do in the compiler and simplifies the interpreter.

I'm going to work on this one. The compiler is probably the area of the CPython codebase with which I'm least familiar, so this will be a good chance to familiarize a bit. There are a few other tasks I'm going to wrap up before starting on this but I'm sure it will be no later than next week.

• Add some bytecodes to generators/co-routines to handle all the corner case code in gen.send(). Callers should not need to check the internal state of the generator, the generator bytecode should handle it.
• Split YIELD_FROM into two. Having two bytecodes allows us to more easily tell whether an exception caused by throw should be passed into sub-generators or not. Again, the caller should not need to know about the internal state of the generator/coroutine.

Interestingly, the generator implementation is a close second to the compiler for me when it comes to familiarity. 🙂 I'll pick one of these up once I'm done with the cell variable offsets.

[markshannon]

Either we've done it, or it's too late.