PEP 570: Python Positional-Only Parameters

[pablogsal (Pablo Galindo Salgado)]

@rhettinger

The problem been solved is mostly an imagined problem. Real users almost never have a problem with CPython as it has been for almost 30 years.

This is not true, as we said in the PEP major 3rd part libraries are already using the “/” notation implementing the feature on their own, like numpy:

https://docs.scipy.org/doc/numpy/reference/ufuncs.html#available-ufuncs

@rhettinger

The / notation in the docstrings has been a failure with users . It is confusing and distracting.

This is covered in the PEP:

Currently users are surprised when first encountering this notation, but
this is to be expected given that it has only recently been adequately
documented [#document-positional-only], and it is not possible to use
it in Python code. For these reasons, this notation is currently an
oddity that appears only in CPython’s APIs developed in C. Documenting
the notation and making it possible to be used in Python code will
certainly eliminate this problem.

@rhettinger

Lastly, the notation looks gross (to my eyes at least). This is a language where we say beauty counts but then seem to be willing to throw it away for something that isn’t an actual problem in userland (or is at least a very, very minor problem that doesn’t interfere with day to day usability). I really don’t want to have to see, write, or teach something like this:

I think this is highly subjective, as you are making an argument based on the perception of “beauty” and that will change massively from person to person. This PEP tries to solve several problems that are described in the document, and we firmly believe that these problems are real and important. The fact that a feature is focused mainly for library developers does not make it less important, as having flexible and stable interfaces is very important, especially for helping with future changes as the PEP describes.

Interfaces evolve over time, and maintaining backwards compatibility for example is something that library developers struggle continuously. Right now there is the danger that every name that you use in your interface needs to be forever or you need to consider breaking users. Not only that, but moving to more flexible interfaces using *args is also a possibility that positional-only parameters allow, all of this with descriptive and explicit signatures (instead of uninformative functions that only receive *args and **kwargs).

@rhettinger

Please don’t do this.

The PEP makes a great effort in describing not only all the situation were positional only arguments are important and solve real problems, but also mentions other very important aspects like the fact that they are needed for compliance with PEP 399. The problems that CPython currently solves with the argument clinic are not unique of CPython, the standard library or C functions, so I don’t see why Python functions in the standard library or external users cannot benefit from it.