[Cython] Fused Types

[Dag Sverre Seljebotn]

On 05/03/2011 08:19 PM, Robert Bradshaw wrote:

>> Btw we shouldn't count on pruning for the design of this, I think this will
>> for a large part be used with def functions. And if you use a cdef function
>> from another module through a pxd, you also need all versions.
>
> Well, we'll want to avoid compiler warnings. E.g. floating might
> include long double, but only float and double may be used. In pxd and
> def functions, however, we will make all versions available.

Which is a reminder to hash out exactly how the dispatch will be 
resolved when coming from Python space (we do want to support "f(x, y)", 
without []-qualifier, when calling from Python, right?)

Fused types mostly make sense when used through PEP 3118 memory views 
(using the planned syntax for brevity):

def f(floating[:] x, floating y): ...

I'm thinking that in this kind of situation we let the array override 
how y is interpreted (y will always be a double here, but if x is passed 
as a float32 then use float32 for y as well and coerce y).

Does this make sense as a general rule -- if there's a conflict between 
array arguments and scalar arguments (array base type is narrower than 
the scalar type), the array argument wins? It makes sense because we can 
easily convert a scalar while we can't convert an array; and there's no 
"3.4f" notation in Python.

This makes less sense

def f(floating x): ...

as it can only ever resolve to double; although I guess we should allow 
it for consistency with usecases that do make sense, such as 
"real_or_complex" and "int_or_float"

The final and most difficult problem is what Python ints resolve to in 
this context. The widest integer type available in the fused type? 
Always Py_ssize_t? -1 on making the dispatch depend on the actual 
run-time value.

Dag Sverre