[Discussion on numfo...@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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
