[Cython] CEP1000: Native dispatch through callables

mark florisson markflorisson88 at gmail.com
Fri Apr 13 16:18:01 CEST 2012

On 13 April 2012 14:27, Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no> wrote:
> 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).

It's not really different, more a response to Stefan's comment.

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

That's fine as long as they use the same way to expose ABI
information. As a courtesy though, we could do it anyway, which makes
it easier for those respective projects to understand what's involved,
how to implement it, and they can then decide whether they want to
ship that project as part of their own project.

> Dag
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel

More information about the cython-devel mailing list