[Cython] CEP1000: Native dispatch through callables

Stefan Behnel stefan_ml at behnel.de
Sun Apr 15 09:30:08 CEST 2012

Dag Sverre Seljebotn, 15.04.2012 08:58:
> Ah, Cython objects. Didn't think of that. More below.
> On 04/14/2012 11:02 PM, Stefan Behnel wrote:
>> thanks for writing this up. Comments inline as I read through it.
>> Dag Sverre Seljebotn, 14.04.2012 21:08:
>>> 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.
>> What about signatures that require an object when we have a C typed value?
>> What about signatures that require a C typed argument when we have an
>> arbitrary object value in our call parameters?
>> We should also strip the "self" argument from the parameter list of
>> methods. That's handled by the attribute lookup before even getting at the
>> callable.
> On 04/15/2012 07:59 AM, Robert Bradshaw wrote:
>> It would certainly be useful to have special syntax for memory views
>> (after nailing down a well-defined ABI for them) and builtin types.
>> Being able to declare something as taking a
>> "sage.rings.integer.Integer" could also prove useful, but could result
>> in long (and prefix-sharing) signatures, favoring the
>> runtime-allocated ids.
> I do think describing Cython objects in this cross-tool CEP would work
> nicely, this is for standardized ABIs only (we can't do memoryviews either
> until their ABI is standard).

It just occurred to me that an object's type can safely be represented at
runtime as a pointer, i.e. an integer. Even if the type is heap allocated
and replaced by another one later, a signature that uses that pointer value
in its encoding would only ever match if both sides talk about the same
type at call time (because at least one of them would hold a life reference
to the type in order to actually use it).

That would mean that IDs for signatures with object arguments would have to
be generated at setup time, e.g. during module init, after importing the
respective type. But I think that's acceptable.

> I think I prefer to a) exclude it now, and b) down the line we need another
> cross-tool ABI to communicate vtables, and then we could put that into this
> CEP now.
> I strongly believe we should go with the Go "duck-typing" approach for
> interfaces, i.e. it is not the declared name that should be compared but
> the method names and signatures.
> The only question that needs answering for CEP1000 is: Would this blow up
> the signature string enough that interning is the only viable option?

That sounds excessive to me. Why would you want to test interfaces of
arguments as part of the signature matching? Isn't that something that the
callee should do when it actually needs a specific interface internally?

Is there an important use case for passing objects with different
interfaces as the same argument into the same callable? At least, it
doesn't sound like such a use case would be performance critical in terms
of the call overhead.


More information about the cython-devel mailing list