[Python-Dev] PEP 575 (Unifying function/method classes) update

[Jeroen Demeyer]

On 2018-05-16 17:31, Petr Viktorin wrote:
> The larger a change is, the harder it is to understand

I already disagree here...

I'm afraid that you are still confusing the largeness of the *change* 
with the complexity of the *result* after the change was implemented.
A change that *removes* complexity should be considered a good thing, 
even if it's a large change.

That being said, if you want me to make smaller changes, I could do it. 
But I would do it for *you* personally because I'm afraid that other 
people might rightly complain that I'm making things too complicated.

So I would certainly like some feedback from others on this point.

> Less disruptive changes tend to have a better backwards compatibility story.

Maybe in very general terms, yes. But I believe that the "disruptive" 
changes that I'm making will not contribute to backwards 
incompatibility. Adding new ml_flags flags shouldn't break anything and 
adding a base class shouldn't either (I doubt that there is code relying 
on the fact that type(len).__base__ is object).

In my opinion, the one change that is most likely to cause backwards 
compatibility problems is changing the type of bound methods of 
extension types. And that change is even in the less disruptive PEP 576.

> Mark Shannon has an upcoming PEP with an alternative to some of the
> issues.

I'm looking forward to a serious discussion about that. However, from a 
first reading, I'm not very optimistic about its performance implications.

> Currently, the "outside" of a function (how it looks when introspected)
> is tied to the "inside" (what happens internally when it's called).
> Can we better enable pydoc/IPython developers to tackle introspection
> problems without wading deep in the internals and call optimizations?

I proposed complete decoupling in https://bugs.python.org/issue30071 and 
that was rejected. Anyway, decoupling of introspection is not the 
essence of this PEP. This PEP is really about allowing custom built-in 
function subclasses. That's the hard part where CPython internals come 
in. So I suggest that we leave the discussion about introspection and 
focus on the function classes.

> But, it still has to inherit from base_function to "look like a
> function". Can we remove that limitation in favor of duck typing?

Duck typing is a Python thing, I don't know what "duck typing" would 
mean on the C level. We could change the existing isinstance(..., 
base_function) check by a different fast check. For example, we 
(together with the Cython devs) have been pondering about a new "type" 
field, say tp_cfunctionoffset pointing to a certain C field in the 
object structure. That would work but it would not be so fundamentally 
different from the current PEP.


*PS*: On friday, I'm leaving for 2 weeks on holidays. So if I don't 
reply to comments on PEP 575 or alternative proposals, don't take it as 
a lack of interest.


Jeroen.