[Cython] CEP 1001 - Custom PyTypeObject extensions

[Dag Sverre Seljebotn]

On 05/13/2012 09:35 PM, Dag Sverre Seljebotn wrote:
> On 05/12/2012 08:44 PM, Nathaniel Smith wrote:
>> On Fri, May 11, 2012 at 2:25 PM, Dag Sverre Seljebotn
>> <d.s.seljebotn at astro.uio.no> wrote:
>>> This comes from a refactor of the work on CEP 1000: A PEP proposal,
>>> with a
>>> hack for use in current Python versions and in the case of PEP
>>> rejection,
>>> that allows 3rd party libraries to agree on extensions to PyTypeObject.
>>>
>>> http://wiki.cython.org/enhancements/cep1001
>>>
>>> If this makes it as a PEP, I don't think we need to think about
>>> having CEP
>>> 1000 accepted as a PEP.
>>>
>>> Comments?
>>
>> There should probably be some discussion of memory management for the
>> tpe_data pointers. (I assume it's "guaranteed to be valid for as long
>> as the associated PyTypeObject, and the PyTypeObject is responsible
>> for making sure any necessary cleanup happens if it gets deallocated",
>> but a note to this effect would be good.)
>>
>> What happens if I want to inherit from PyTypeObject (a "metaclass")
>> and also implement this interface? It is possible? What if I want to
>> inherit from an existing subclass of PyTypeObject and add on this
>> interface? I don't know enough gnarly details about how new style
>> classes are implemented to tell. Would it make sense to make this
>> memory-layout-equivalent to a PyTypeObject subclass with extra fields?
>
> Hmm. You know what -- this whole thing could probably be a metaclass.
> Except I think a PyObject_TypeCheck on the type would be a bit more
> expensive than just checking a flag. I think I like having a flag better...
>
> The point of supporting objects with a metaclass is a good one. I don't
> know enough details either. I wonder if ob_size field could save us;
> basically access extra information at offset
>
> (ob_size != 0) ? ob_size : sizeof(PyTypeObject);

Ehrm, presumably the size information must include the size of the extra 
payload, so this computation must be a bit different...

Anyway, thanks for the heads up, this seems to need a bit more work. 
Input from somebody more familiar with this corner of the CPython API 
very welcome.

Dag

>
> I think that also flags that the type object is allocated on heap? But
> at least it allows a way out of you want to use a metaclass (allocate it
> on the heap; or perhaps give it a very high refcount).
>
> But I didn't check this in detail yet.
>
> Dag