[Cython] CEP1000: Native dispatch through callables

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Fri Apr 13 15:27:34 CEST 2012


On 04/13/2012 03:01 PM, mark florisson wrote:
> On 13 April 2012 13:48, Stefan Behnel<stefan_ml at behnel.de>  wrote:
>> Stefan Behnel, 13.04.2012 14:27:
>>> Dag Sverre Seljebotn, 13.04.2012 13:59:
>>>> Requiring interning is somewhat less elegant in one way, but it makes a lot
>>>> of other stuff much simpler.
>>>>
>>>> That gives us
>>>>
>>>> struct {
>>>>      void *pointer;
>>>>      PyBytesObject *signature;
>>>> } record;
>>>>
>>>> and then you allocate a NULL-terminated arrays of these for all the overloads.
>>>
>>> However, the problem is the setup. These references will have to be created
>>> at init time and discarded during runtime termination. Not a problem for
>>> Cython generated code, but some overhead for hand written code.
>>>
>>> Since the size of these structs is not a problem, I'd prefer keeping Python
>>> objects out of the game and using an ssize_t ID instead, inferred from a
>>> char* signature at module init time by calling a C-API function. That
>>> avoids the need for any cleanup.
>>
>> Actually, we could even use interned char* values. Nothing keeps that C-API
>> setup function from reassigning the "char* signature" field to the char*
>> buffer of an internally allocated byte string. Except that we'd have to
>> *require* users to use literals or otherwise statically allocated C strings
>> in that field. Hmm, maybe not the best idea ever...
>>
>> Stefan
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>
> You could create a module shared by all versions and projects, which
> exposes a function 'get_signature', which given a char *signature
> returns the pointer that should be used in the ABI signature type
> information. You can then always compare by identity.

I fail to see how this is different from what I proposed, with interning 
bytes objects (which I still prefer; although the binary-search features 
of direct comparison makes that attractive too).

BTW, any proposal that requires an actual project/library that both 
Cython and NumPy depends on will fail in the real world.

Dag


More information about the cython-devel mailing list