[Cython] Fused Types

[Robert Bradshaw]

On Thu, Apr 28, 2011 at 1:31 PM, mark florisson
<markflorisson88 at gmail.com> wrote:
> On 28 April 2011 22:12, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>> On Thu, Apr 28, 2011 at 12:48 PM, mark florisson
>> <markflorisson88 at gmail.com> wrote:
>>
>>> So I fixed all that, but I'm currently wondering about the proposed
>>> cython.typeof(). I believe it currently returns a string with the type
>>> name, and not the type itself.
>>
>> Yes. This is just because there's not really anything better to return
>> at this point. We should "fix" this at some point in the future.
>>
>>> So I think it would be inconsistent to
>>> suddenly start allowing comparison with 'is' and 'isinstance' and
>>> such.
>>
>> I'm open to other suggestions, but would like an expression that
>> resolves at compile time to true/false (and we need to do branch
>> pruning on it). Note that type() is not good enough, because it has
>> different semantics, i.e.
>>
>>    cdef object o = []
>>    typeof(o), type(o)
>>
>> so lets not touch that one.
>
> Right, so for fused types I don't mind string comparison with
> cython.typeof(), but retrieval of the actual type for casts and
> declaration remains open. I'd be fine with something like
> cython.gettype().

I'd rather re-use typeof here than introduce yet another special
method. On the other hand, allowing parentheses in a type declaration
requires complicating the syntax even more.

I'm not sure this is needed, couldn't one do

    cdef foo(fused_type a):
        cdef fused_type b = a + <fused_type>func()

and all instances of fused_type get specialized in the body.

> On the other hand, the user could already do this thing by manually
> declaring another fused type that would perhaps be resolved based on
> its usage. e.g. for my original example:
>
> ctypedef char *string_t
> ctypedef cython.fused_type(int, string_t) attrib_t
>
> cdef func(struct_t mystruct, int i):
>    cdef attrib_t var = mystruct.attrib + i
>
> Is this something that should be supported anyway?

OK, I take back what I said, I was looking at the RHS, not the LHS. If
one needs to specialize in this manner, explicitly creating two
branches should typically be enough. The same for casting. The one
exception (perhaps) is "my_fused_type complex." Otherwise it's
starting to feel too much like C++ template magic and complexity for
little additional benefit.

> Currently fused
> types can only be used when appearing as argument types (in the
> function body and as return value).

>>> I'm also wondering if it would be useful to allow actual type
>>> retrieval, which could be used in declarations and casts. For instance
>>> consider fusing two structs with the same attribute name but different
>>> attribute types. Perhaps in your code you want to introduce a variable
>>> compatible with such a type, e.g. consider this:
>>>
>>> ctypdef struct A:
>>>    int attrib
>>>
>>> ctypedef struct B:
>>>    char *attrib
>>>
>>> ctypedef cython.fused_type(A, B) struct_t
>>>
>>> cdef func(struct_t mystruct, int i):
>>>    cdef cython.gettype(mystruct.attrib) var = mystruct.attrib + i
>>>    ...
>>>
>>> What do you think?
>>
>> Yes, I was thinking that would be supported as well.
>>
>> - Robert
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>