PEP 718: Specify binding, parametrisation and overload interactions #4649
Conversation
|
All commit authors signed the Contributor License Agreement. |
|
Please can someone get the CLA bot to re-run? I'm not sure why it's requesting that email TBH. I've already signed it for my email [email protected] |
Sorry I can't test I can't get make installed
|
I don't think that the word "subscription" is being used correctly. |
You committed with your Git client configured with that email, see https://github.com/python/peps/pull/4649.patch You also need to sign it with that. |
| the runtime type. The only change is that more situations will be decidable and the | ||
| behaviour/overload can be specified by the developer rather than leaving it to ordering | ||
| of overloads/unions. | ||
| Overloaded functions should work much the same as they already do, since they do not |
There was a problem hiding this comment.
I guess this is about the runtime behavior of calling overloaded functions?
| of overloads/unions. | ||
| Overloaded functions should work much the same as they already do, since they do not | ||
| affect the runtime type. Explicit specialisation will restrict the set of available | ||
| overloads. |
There was a problem hiding this comment.
It's worth spelling out in detail how this would work. What I'd expect is that if the function is subscripted, only those overloads are considered for which the subscription may succeed. So if you have an overload make[*Ts], one with make[T], and one with just make, then a call to make[int] will only consider the first and second, and a call to make[int, str] will only consider the first. This could be another step in the overload resolution spec before all the current steps.
PEP 123: Summary of changes)📚 Documentation preview 📚: https://pep-previews--4649.org.readthedocs.build/