[Cython] CEP1000: Native dispatch through callables

Stefan Behnel stefan_ml at behnel.de
Sun Apr 15 08:37:10 CEST 2012


Robert Bradshaw, 15.04.2012 08:27:
> On Sat, Apr 14, 2012 at 2:02 PM, Stefan Behnel wrote:
>> While overloaded signatures are great for the callee, they make things much
>> more complicated for the caller. It's no longer just one signature that
>> either matches or not. Especially when we allow more than one expected
>> signature, then each of them has to be compared against all exported
>> signatures.
>>
>> We'll have to see what the runtime impact and the impact on the code
>> complexity is, I guess.
> 
> The caller could choose to only check the first signature to avoid
> complexity. I think, however, that overloaded signatures are
> important, and even checking a dozen is cheaper than going through the
> Python call. Fused types naturally lead to overloads as well.

Hmm, maybe it wouldn't even be all that inefficient. If both sides sorted
their signatures by highest efficiency at compile time, the first hit would
cut down the number of signatures that need further comparison to the ones
before the match.


>>> each described by a function pointer and a signature specification
>>> string, such as "id)i" for {{{int f(int, double)}}}.
>>
>> How do we deal with object argument types? Do we care on the caller side?
>> Functions might have alternative signatures that differ in the type of
>> their object parameters. Or should we handle this inside of the caller and
>> expect that it's something like a fused function with internal dispatch in
>> that case?
>>
>> Personally, I think there is not enough to gain from object parameters that
>> we should handle it on the caller side. The callee can dispatch those if
>> necessary.
> 
> I don't think we should prohibit the signature from being able to
> declare arbitrary Cython types.  Whether it proves useful is dependent
> on the library, and is the library writer's choice.

It leads to very different requirements for the signature encoding/syntax,
though. I think we should only go that route when we think we have to.


>>>  * Requires a registry for interning strings. This must be
>>>    "handshaked" between the implementors of this CEP (probably by
>>>    "first to get at {{{sys.modules["_nativecall"}}} sticks it there),
>>>    as we can't ship a common dependency library for this CEP.
>>
>> ... which would eventually end up in the stdlib, but could equally well
>> come from PyPI for now. I don't see a problem with that.
>>
>> Using sys.modules (or another global store) instead of an explicit import
>> allows for dependency injection, that's good.
> 
> It excludes (or makes it difficult) for non-Python libraries to participate.

True, but that can be helped by providing a library (or header file) that
provides simple C calls for the required setup.

Stefan


More information about the cython-devel mailing list