[Cython] Fused Types

Stefan Behnel stefan_ml at behnel.de
Fri Apr 29 04:09:56 CEST 2011

mark florisson, 28.04.2011 23:29:
> On 28 April 2011 22:31, mark florisson wrote:
>> On 28 April 2011 22:12, Robert Bradshaw wrote:
>>> On Thu, Apr 28, 2011 at 12:48 PM, mark florisson 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().
> It seems that this isn't optimized yet, but it looks to me like it
> wouldn't be very hard to do so. At least == and != could be resolved
> at compile time if the other operand is a string literal.

Well, the obvious place where this would happen for free would be constant 
folding. But that runs *way* before type analysis, so all it sees is the 
typeof() call, not the string.

Optimising this would thus basically require a second (simpler?) constant 
folding step, or at least an additional hook during (or after) type 
analysis that does the comparison. I wouldn't mind too much, given that 
type analysis can end up injecting some rather handy information into the 
tree. So a second (even complete) constant folding step *after* type 
analysis may still introduce some nice optimisations.

We may actually consider splitting constant folding into two steps - one 
that calculates the results as early as possible (and maybe does only 
safe&obvious tree replacements, e.g. boolean values, strings, etc.) and a 
second step that replaces subtrees by constant nodes once it knows the 
final type of the result.


More information about the cython-devel mailing list