py: Implement PEP 570, positional-only parameters. - #19799

Summary

This PR implements PEP 570: positional-only parameters, which are annotated via a "/" in the function/lambda parameter list; see https://peps.python.org/pep-0570/

The implementation is simple: positional-only parameters are given the name MP_QSTRnull in the prelude, so keyword matching at runtime in mp_setup_code_state_helper() does not match against them. This approach gets the same semantics as CPython while keeping the runtime and .mpy format unchanged.

This PR is an alternative to #8480. The benefit of this one here is that it does not require a change to the .mpy file format. So code compiled with mpy-cross prior to this PR will work on VM's post this PR.

Inspecting generated bytecode is the best way to see how this feature works. For the function definition:

def f(a, b, c):
    pass

The qstr table in the corresponding .mpy file looks like:

qstr_table[6] (* for static qstrs):
    'x.py'
    '<module>' *
    'f'
    'a'
    'b'
    'c'

and the bytecode for the function f is:

1b:0a:02:03:04:05:20:51:63

The 02:03:04:05 bytes are indices into qstr_table for the function name and then the three parameter names.

Changing that function to use positional-only parameters:

def f(a, b, c, /):
    pass

the qstr table is now:

qstr_table[4] (* for static qstrs):
    'x.py'
    '<module>' *
    'f'
    None *

and the bytecode for f is:

1b:0a:02:03:03:03:20:51:63

This is the same number of bytes as before, but the parameter names are the 03:03:03 bytes which index the None entry in qstr_table. The total .mpy file size is eight bytes smaller here because it no longer stores the three parameter names.

The user-facing differences to CPython are minimal:

• In MicroPython, locals() doesn't know about the positional-only parameter names. But MicroPython already doesn't support local function variables in locals().
• Error messages are slightly different.

For an example of a different error message, consider executing:

def f(a, /): pass
f(a=1)

CPython gives:

TypeError: f() got some positional-only arguments passed as keyword arguments: 'a'

whereas MicroPython gives:

TypeError: unexpected keyword argument 'a'

Testing

Tests are added to the standard test suite and will be run under CI on all targets (the feature is not optional, so all ports will get it).

Trade-offs and Alternatives

• This will cost a small amount of code size but should be relatively minimal. It's a standard syntax feature of CPython 3.8+ so it's worth having it enabled unconditionally.
• RAM usage and size of .mpy data is increased slightly only in rare cases compiling code that includes the "*" string as well as closures (because now the compiler uses MP_QSTR__star_ as well as MP_QSTRnull in the generated mpy data). In the entire micropython-lib library totaling about 600k bytes of .mpy data, the changes here added only +20 bytes to that.
• Performance is the runtime should be unchanged because there are no changes to the runtime.
• Error messages here are less informative than CPython (just "invalid syntax") but that follows existing practices in the compiler.
• This is an alternative to pep 570 positional only parameters. #8480. The PR here is pretty much equivalent to that one in the grammar and compiler. But the emitter is different: here, the bytecode emits MP_QSTRnull for each positional-only parameter, whereas in pep 570 positional only parameters. #8480 the bytecode has a modified prelude which stores the number of positional-only parameters. So the difference is really just the way things are encoded in the mpy file. pep 570 positional only parameters. #8480 is slightly more efficient in use of space for functions with many (4 or more) positional-only parameters, but has overhead in the runtime extracting and using the new number in the prelude. The approach in this PR has no changes to the runtime and no additional overhead there when using positional parameters. It's also backwards compatible with the .mpy format.

Generative AI

I used Claude Opus 5.5 to discuss the problem of implementing PEP 570 and brainstorm some alternative ways of doing it. It came up with the approach here, but I implemented it all by hand. Claude also wrote some of the tests in this PR, and reviewed the commits (finding a few bugs along the way, like the need to use MP_QSTRnull instead of MP_QSTR__star_).