On 28 April 2011 23:30, Robert Bradshaw <rober...@math.washington.edu> wrote:
> On Thu, Apr 28, 2011 at 1:31 PM, mark florisson
> <markflorisso...@gmail.com> wrote:
>> On 28 April 2011 22:12, Robert Bradshaw <rober...@math.washington.edu> wrote:
>>> On Thu, Apr 28, 2011 at 12:48 PM, mark florisson
>>> <markflorisso...@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.
Right, that is supported already.
>> 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.
Ok, branching on the type sounds fine to me. It brings one problem
though: because you cannot declare the variables of your variable type
(the type of say, mystruct.attrib), you will need to do multiple
declarations outside of your branches. So in my example:
cdef func(struct_t mystruct, int i):
cdef string_t string_var
cdef int int_var
if typeof(mystruct) is typeof(int):
int_var = mystruct.attrib + i
...
else:
string_var = mystruct.attrib + i
...
But this is probably not a common case, so likely not an issue.
>> 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@python.org
>>> http://mail.python.org/mailman/listinfo/cython-devel
>>>
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel@python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>>
> _______________________________________________
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
