Thanks Pablo.

Noting for the record: positional-only arguments aren't new *semantically", since extension modules have always allowed them, and you've long been able to emulate them in Python code by accepting "*args".

Prior to the introduction of argument clinic and __text_signature__, the inspect module wouldn't report *anything* particularly useful for affected signatures, so folks have long built argument introspection based systems around the assumption that they will only be passed functions that they can successfully introspect.

The introduction of a Python level syntax for positional-only arguments doesn't change that logic, as all a consuming application has to do to be compatible with them is to adopt the principle "if an argument can be supplied positionally, it will be supplied positionally", and then only use keywords for keyword-only arguments.

Alternatively, consuming frameworks are also free to make "don't use positional-only arguments" a constraint on the callable inputs they accept.

That said, we *may* want to add a "num_position_only" attribute to FullArgSpec that isn't part of the tuple unpacking, for similar reasons to why we undeprecated getfullargspec in the first place: the easiest way to migrate from getfullargspec to Signature is to write a wrapper API, and if the existence of a wrapper API is inevitable (as I now believe it is, after our experience with the first attempted deprecation), we may as well maintain a properly tested one in the standard library, rather than seeing multiple variants of the same code spring up elsewhere.