Robert Bradshaw, 29.04.2011 06:32:
On Thu, Apr 28, 2011 at 7:09 PM, Stefan Behnel<stefan...@behnel.de> wrote:
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.
Actually, to support code like
ctypedef cython.fused_type(object, double) my_fused_type
cdef foo(my_fused_type x):
if my_fused_type is object:
print x.attr
else:
cdef my_fused_type *ptr =&x
we need to resolve this branch and prune "dead code" before type
analysis, so I'm thinking it may need to be a special phase, perhaps
part of the fused-type-specialization phase. Here's another idea:
cdef foo(numeric x):
if numeric in floating:
...
elif numeric is long:
...
else:
...
print numeric is double # after the specialization pass, this
would be a literal True/False node.
Again, this would all be resolved before type analysis.
Hmm, I wonder, if we ever want to start with whole program analysis, and we
find code like this:
def func(arg):
...
a = [1,2,3]
func(a)
we could infer that "arg" is actually a "fused_type(object, list)". So, I
think, what we eventually want is an intermingling of type analysis and
specialisation. Meaning, we'd find a new type during type analysis or
inference, split off a new version of the function and then analyse it. But
maybe that's just a pie in the sky for now.
Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
