Automate positional arguments in clinic code about cpython HOT 14 CLOSED

Could we do this deprecation as soon as possible with a list of all affected functions?

We'd need to approach such a deprecation extremely carefully. Each function changed would have to be evaluated separately to see if the tradeoff would be worth it for users of CPython. For each function, we'd have to consider:

• How common is it to pass a keyword argument to the parameter(s) we're considering changing? If it's common, and/or if it makes sense to be able to pass it by keyword, it may not be worth the disruption
• How much of a speedup are we talking for that function?
• How likely is it that that function would be used in performance-critical areas of a codebase, such that speeding up the function would offer a meaningful and noticeable improvement for users of CPython?

This isn't to say that we shouldn't make any changes here, necessarily. If there are builtin functions where it really makes no sense to pass an argument by keyword, it would speed the function up a lot to make a parameter positional-only, and we can't really find any uses in the wild of people passing it by keyword — for those functions, I think we could definitely consider starting a deprecation cycle so that we can eventually make them positional-only. We definitely can't do them all at once, though, I'm afraid :-)

from cpython.

I also think we should start with the private functions (starting with an underscore).
For those functions we just need to check if they're not exported as public functions.
(And of course don't break code in the stdlib).

from cpython.

Alex, you should probably also add the performance label, as this could greatly improve CPython's performance. :)

Unfortunately I don't think we'd see any immediate performance gains, as we'd have to undergo a deprecation period of at least two release cycles before making any parameters that are currently positional-or-keyword positional-only :/

from cpython.

This would break a lot of code. I don't think this is a good idea.

from cpython.

Won't this be mostly used for functions with readability problems or an unintuitive order, and usage with something like functools.partial()

It's pretty hard to say in the abstract, which is why we'd need to consider each function individually before making a decision on whether to start the deprecation cycle :-) but anything that would require people to change code that was previously working counts as a backwards-compatibility breakage, so is subject to the policy in PEP-387

from cpython.

cc @erlend-aasland, @eendebakpt

from cpython.

Alex, you should probably also add the performance label, as this could greatly improve CPython's performance. :)

from cpython.

Damn that's really unfortunate. ;( Could we do this deprecation as soon as possible with a list of all affected functions?

from cpython.

But which code? I'm talking about functions with only required arguments.
All I can think of is usage with functools.partial() which wouldn't apply to functions with a single argument!

from cpython.

We'd need to approach such a deprecation extremely carefully. Each function changed would have to be evaluated separately to see if the tradeoff would be worth it for users of CPython.

I agree, though we should use an approach that minimizes the required work (like only evaluating functions with 2 or more
required arguments and skipping infrequently used modules).

How common is it to pass a keyword argument to the parameter(s) we're considering changing? If it's common, and/or if it makes sense to be able to pass it by keyword, it may not be worth the disruption

Won't this be mostly used for functions with readability problems or an unintuitive order, and usage with something like functools.partial() (which doesn't apply to functions with a single argument)?

We definitely can't do them all at once, though, I'm afraid

That's fine, but it's important that we discuss this.

from cpython.

Could we consider automatically updating all current clinic input to explicitely allow keyword arguments like in the proposal, and make arguments positional only by default if no keywords are provided?
Or would that lead to too many merge conflicts?

from cpython.

Could we consider automatically updating all current clinic input to explicitely allow keyword arguments like in the proposal, and make arguments positional only by default if no keywords are provided? Or would that lead to too many merge conflicts?

I'm not sure I fully understand what you're proposing here, sorry

from cpython.

OK, so we simply convert this code:

 /*[clinic input] 
 os._path_normpath 
  
     path: object 
  
 Basic path normalization. 
 [clinic start generated code]*/ 

To this:

 /*[clinic input] 
 os._path_normpath 
  
     /
     path: object 
  
 Basic path normalization. 
 [clinic start generated code]*/ 

That's it. Oops, that's not supported:

Error in file 'Modules/posixmodule.c' on line 5473:
Function '_path_normpath' has an unsupported group configuration. (Unexpected state 0.d)

from cpython.

Well, I guess this can be closed then for the time being.

from cpython.