-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
PEP 718: Specify binding, parametrisation and overload interactions #4649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Co-authored-by: Jelle Zijlstra <[email protected]>
|
@Gobot1234 please if you need help don't hesitate to ask, I'm very interested on this feature and would be a pity to see it abandoned |
|
@JelleZijlstra Is there something I can do to move the needle on this PEP if the original author don't reply in a reasonable amount of time? like contributing to the writing of this PEP? |
|
@Gobot1234 is still around, I'd wait a bit longer. But this PEP has been sitting for a long time and as I've written on Discuss before, I personally have some reservations about it. If you're interested in renewing the discussion and addressing the concerns that have been raised about the PEP, you could work with James to improve the PEP, or even write your own replacement PEP. |
|
@JelleZijlstra I already wrote James in Discourse, in GitHub and in private offering my help on September, after that he did reappear (but didn't particularly requested my help). Now is almost a month without updates from him and I would really like to see this coming in python 3.15 (if is approved etc ofc), given that he did vanish for more than a year last time (look in discourse the message of Guido on 7 May 2023), I think is reasonable to move forward with the PEP after almost a month without updates from him. So how can I do my own PEP replacement / edit this? Would I count with your sponsorship or the original one from @gvanrossum ? thanks in advance |
|
You'd need a new sponsor. I'm not currently interested in sponsoring a version of this PEP, but another core dev might be. |
|
@PabloRuizCuevas I'm happy to review stuff for it and would happily add you as a co-author. I just don't really have the time/motivation to finish it as my usage of python is so little nowadays |
|
Alas, I can't take on sponsoring a new PEP either. But I will continue to fulfill my promises on the old one. As a sponsor, I have to ask: what are the chances that the Typing Council will approve this PEP? That's the first and most important hurdle for typing PEPs. |
|
Ok I will help @Gobot1234 on finishing this one, @JelleZijlstra answering the concerns of Guido, and given that you belong to the typing council (right?), do you think that this PEP has any chance of being approved? If there is chances what would be the priority changes for me to make to advance on it. thanks in advance. I guess the overload resolution as you already pointed out is one of them, right? anything else? I was planning to add other examples, motivations and ideas that were mentioned in discourse. |
|
I don't know what the Typing Council will decide but I wrote this last year: https://discuss.python.org/t/pep-718-subscriptable-functions/28457/38 and still feel the motivation for the PEP is weak. |
PEP 123: Summary of changes)📚 Documentation preview 📚: https://pep-previews--4649.org.readthedocs.build/