[Cython] CEP1000: Native dispatch through callables

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Sun Apr 15 11:13:51 CEST 2012

Nathaniel Smith <njs at pobox.com> wrote:

>On Sun, Apr 15, 2012 at 9:07 AM, Dag Sverre Seljebotn
><d.s.seljebotn at astro.uio.no> wrote:
>> On 04/15/2012 09:30 AM, Stefan Behnel wrote:
>>> 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
>>>>>> string, such as "id)i" for {{{int f(int, double)}}}.
>>>>> How do we deal with object argument types? Do we care on the
>>>>> side?
>>>>> Functions might have alternative signatures that differ in the
>type of
>>>>> their object parameters. Or should we handle this inside of the
>>>>> and
>>>>> expect that it's something like a fused function with internal
>>>>> in
>>>>> that case?
>>>>> Personally, I think there is not enough to gain from object
>>>>> 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
>>>>> value?
>>>>> What about signatures that require a C typed argument when we have
>>>>> arbitrary object value in our call parameters?
>>>>> We should also strip the "self" argument from the parameter list
>>>>> 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
>>>>> (after nailing down a well-defined ABI for them) and builtin
>>>>> Being able to declare something as taking a
>>>>> "sage.rings.integer.Integer" could also prove useful, but could
>>>>> in long (and prefix-sharing) signatures, favoring the
>>>>> runtime-allocated ids.
>>>> I do think describing Cython objects in this cross-tool CEP would
>>>> 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
>>> and replaced by another one later, a signature that uses that
>>> value
>>> in its encoding would only ever match if both sides talk about the
>>> type at call time (because at least one of them would hold a life
>>> reference
>>> to the type in order to actually use it).
>> The missing piece here is that both me and Robert are huge fans of
>> polymorphism. If you haven't read up on that I highly recommend it,
>> idea is if you agree on method names and their signatures, you don't
>have to
>> have access to the same interface declaration (you don't have to call
>> interface the same thing).
>Go style polymorphism is certainly a neat idea, but two points:
>- You can't do this kind of matching via signature comparison. If I
>have a type with methods "foo", "bar" and "baz", then that should
>match the interface {"foo", "bar", "baz"}, but also {"foo", "bar"},
>{"foo", "baz"}, {"bar"}, {}, etc. To find the right function for such
>a type, you need to decode each function signature and check them in
>some structured way. Unless your plan is to precompute the hash of all
>2**n interfaces that each object fulfills.

You are of course right this needs a lot more thought.

>- Adding a whole new type system with polymorphic dispatch is a heck
>of a thing to do in a spec for boxing and unboxing pointers. Honestly
>at this level I'm even leery of describing Python objects via their
>type, as opposed to just "PyObject *". Just let the callee do the type
>checking if they need to, and if it later turns out that there are
>actually enough cases where Cython knows the exact type at compile
>time and is dispatching through a boxed pointer and the callee type
>checking is significant overhead, then extend the spec then.

We are not insane, it's been said several times this goes in a later spec. We're just trying to guess whether future developments would seriously impact intern vs. strcmp -- ie what a likely signature length is in the future. We make CEP1000 a simple spec, but spend some time to try to guess how it could be extended.


>-- Nathaniel
>cython-devel mailing list
>cython-devel at python.org

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

More information about the cython-devel mailing list