[Cython] CEP 1001 - Custom PyTypeObject extensions

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Sun May 13 21:35:35 CEST 2012

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);

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.


More information about the cython-devel mailing list