[Cython] SEP 201 draft: Native callable objects

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Thu May 31 16:04:12 CEST 2012


[Discussion on numfocus at googlegroups.com please]

I've uploaded a draft-state SEP 201 (previously CEP 1000):

https://github.com/numfocus/sep/blob/master/sep201.rst

"""
Many callable objects are simply wrappers around native code. This holds 
for any Cython function, f2py functions, manually written CPython 
extensions, Numba, etc.

Obviously, when native code calls other native code, it would be nice to 
skip the significant cost of boxing and unboxing all the arguments.
"""


The thread about this on the Cython list is almost endless:

http://thread.gmane.org/gmane.comp.python.cython.devel/13416/focus=13443

There was a long discussion on the key-comparison vs. interned-string 
approach. I've written both up in SEP 201 since it was the major point 
of contention. There was some benchmarks starting here:

http://thread.gmane.org/gmane.comp.python.cython.devel/13416/focus=13443

And why provide a table and not a get_function_pointer starting here:

http://thread.gmane.org/gmane.comp.python.cython.devel/13416/focus=13443

For those who followed that and don't want to read the entire spec, the 
aspect of flags is new. How do we avoid to duplicate entries/check 
against two signatures for cases like a GIL-holding caller wanting to 
call a nogil function? My take: For key-comparison you can compare under 
a mask, for interned-string we should have additional flags field.

The situation is a bit awkward: The Cython list consensus (well, me and 
Robert Bradshaw) decided on what is "Approach 1" (key-comparison) in SEP 
201. I pushed for that.

Still, now that a month has passed, I just think key-comparison is too 
ugly, and that the interning mechanism shouldn't be *that* hard to code 
up, probably 500 lines of C code if one just requires the GIL in a first 
iteration, and that keeping the spec simpler is more important.

So I'm tentatively proposing Approach 2.

Dag


More information about the cython-devel mailing list