[Python-ideas] Module lifecycle: simple alternative to PEP 3121/PEP 489

[Nikita Nemkin]

On Fri, Apr 15, 2016 at 2:24 PM, Petr Viktorin <encukou at gmail.com> wrote:
>>
>> 1) define a new "calling convention" flag like METH_GLOBALS.
>> 2) store module ref in PyCFunctionObject.m_module
>>     (currently it stores only the module name)
>
> Wouldn't that break backwards compatibility, though?

It will, and I consider this level of breakage acceptable. Alternatively,
another field can be added to this struct.

> My planned approach is a bit more flexible:
> - Add a reference to the module (ht_module) to heap types
> - Create a calling convention METH_METHOD, where methods are passed the
> class that defines the method (which might PyTYPE(self) or a superclass
> of it)
>
> This way methods can get both module state and the class they are
> defined on, and the replacement for PyModule_State is two indirections.

I've read the linked import-sig thread and realized the depth of issues
involved...
Those poor heap type methods don't even have access their own type
pointer! In the light of that, your variant is more useful than mine.

Still, without a good slot support option, new METH_X conventions
don't look attractive at all. Such fundamental change, but only solves
half of the problem.

Also, MRO walking is actually not as slow as it seems.
Checking Py_TYPE(self) and Py_TYPE(self)->tp_base *inline*
will minimize performance overhead in the (very) common case.

If non-slot methods had a suitable static anchor (the equivalent
of slot function address for slots), they could use MRO walking too.