Python 3.8 alpha makes positional-only APIs available in Python

A parameter name can become a compatibility promise simply because callers are allowed to use it as a keyword. Python 3.8's positional-only syntax gives Python function authors a way to keep that name out of the calling contract. The final planned alpha is an opportunity to examine that distinction while the release is still under development.

Python 3.8.0a4 was released on May 6, 2019. The announcement describes it as an early developer preview and the last of four planned alphas. It is not recommended for production. New capabilities remain subject to the development process, so the useful question is what the available implementation lets library authors express today.

The documentation at the alpha tag describes the slash syntax alongside assignment expressions. It explicitly connects the slash to the notation already displayed for functions implemented in C. The change makes the restriction expressible in an ordinary Python function definition.

I like Python's protocol-based approach when a library can participate in the language without forcing callers into a separate style. Matching the callable contracts of native implementations is consistent with that preference. The benefit here is control over which details of a function definition become obligations to its users.

A name can remain an implementation detail

Parameters before the slash must be supplied positionally. For a function whose arguments represent an ordered operation, this makes the call depend on order without also promising that the author's chosen local names remain valid keywords. Renaming such a parameter does not invalidate a keyword spelling because that spelling was never accepted.

A small example makes the boundary explicit.

def difference(left, right, /):
    return left - right

result = difference(12, 5)

This definition accepts the positional call shown. A call using difference(left=12, right=5) does not satisfy the declared parameter rules. The slash applies to both preceding names. It is part of the signature syntax, not a value that callers supply.

That restriction has a cost. Keyword calls can improve clarity, particularly when several arguments have similar types or meanings. Making parameters positional-only removes that option. The syntax is therefore useful when a function actually needs the restriction, including compatibility with an existing callable, rather than as a default formatting preference.

The alpha documentation's example includes a positional-only parameter with a default value. A default does not make that parameter keyword-capable. Whether the caller can omit a value and whether the caller can name a value are separate properties of the signature. Keeping those properties separate makes the new notation easier to interpret.

Native and Python implementations can describe similar contracts

The documentation points out that the slash is the same notation displayed by help for C functions through Argument Clinic. That connection is relevant to libraries that expose comparable operations through different implementations. An ordinary Python definition can now express a positional restriction directly in its signature.

The change also improves what a reader can learn from the definition itself. Without an explicit signature restriction, a function author might rely on documentation to discourage keyword use. The interpreter can now enforce the condition as part of argument binding. The rule is visible where the rest of the parameter contract already lives.

This is a language-level addition with library-design consequences. It does not make all native functions interchangeable with Python definitions. It addresses one specific difference in how an author can specify accepted calls. Other behavior still depends on the function and its implementation.

Debugging native extensions has another compatibility change

The same alpha documentation records a change to debug-build compatibility. On Unix, a debug Python can load extensions built in release mode and extensions using the stable ABI. The explanation identifies the relationship between Py_DEBUG and Py_TRACE_REFS as the cause of the earlier ABI difference.

Defining Py_DEBUG no longer implies Py_TRACE_REFS. Reference tracing remains available through the separate --with-trace-refs configure option. The documentation says that tracing adds the ABI incompatibility. Separating it from the ordinary debug configuration allows more extension binaries to work with a debug interpreter.

For an ecosystem whose useful libraries often depend on native code, that distinction matters. Debugging the interpreter and rebuilding every extension are different tasks. Improving compatibility can let the former proceed without always requiring the latter. This is specifically a statement about the documented Unix compatibility change, not a claim that every binary works with every interpreter.

I find that change at least as relevant as new expression syntax. Python's value often comes from code supplied through its extension mechanisms. Making those extensions easier to use while investigating runtime behavior reduces a practical obstacle around the language's existing strengths.

The alpha exposes contracts before they are final

The release's draft documentation also describes a separate bytecode-cache tree through PYTHONPYCACHEPREFIX or -X pycache_prefix. That moves implicit caches away from each source directory. It is another example of a runtime setting whose effects extend beyond the Python statements in an application.

The point of the alpha is that these behaviors can be exercised together in an actual interpreter build. Function signatures affect callers, while ABI and cache settings affect the environment in which code runs. The release remains a preview, but it already provides concrete contracts for library authors to inspect before the next development phase.