<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 25 March 2018 at 07:38, Jeroen Demeyer <span dir="ltr"><<a href="mailto:J.Demeyer@ugent.be" target="_blank">J.Demeyer@ugent.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Nick Coghlan,<br>
<br>
First of all, thanks for your insightful comments!<span class=""><br>
<br>
On 2018-03-24 09:09, Nick Coghlan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As Antoine notes, unifying user-defined functions and builtin functions<br>
would be fraught with backwards compatibility problems, so you probably<br>
don't want to go down that path when your goal is "Let third parties<br>
define types that are recognised by the core interpreter as being<br>
user-defined functions".<br>
</blockquote>
<br></span>
First of all, my post was mainly meant to get an answer to "is this idea PEP-able?". I have never written a PEP and PEP 1 recommends this step. So it's not clear whether you want to say "that potential PEP is a bad idea" or just "go ahead with your PEP but be aware of backwards compatibility issues".<br>
<br>
It would be good to know what your backwards compatibility worries are. If I have a clearer idea of what could break, it would be easier to see if it's possible to not break that.<br></blockquote><div><br></div><div>The biggest problem would have been the potential change to the descriptor behaviour - making CPython's C functions behave like instance methods instead of static methods would create a significant compatibility risk for no clear benefit.<br><br></div><div>However, from the rest of your email, it sounds like you're not actually proposing to change that and I'd just misunderstood what you were suggesting, so I now think it's a promising idea that should help not only Cython, but also other binding generation projects like cffi, SWIG, Boost, etc :)<br><br></div><div>Cheers,<br></div><div>Nick.<br><br><div>P.S. You're also right that I'd missed the fact that the fast paths that you want to follow at runtime are the PyCFunction ones, so you really do need to be able to define a hybrid type that executes like a builtin C function, but supports introspection like a native Python function.<br></div></div></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>