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.
Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
