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

Jeroen Demeyer J.Demeyer at UGent.be
Wed May 16 16:34:26 EDT 2018

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 basefunction 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.

More information about the Python-Dev mailing list