[Cython] HTML Coverage reports
Hi, I enabled HTML coverage report generation for the test suite. It's now available from the "HTML Coverage Reports" link of the coverage job: https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-py27-coverage/doclinks/1/ From a quick look, the test coverage seems not too bad and we are mostly lacking error tests. However, especially the branch coverage analysis hints at a couple of cases that are worth looking into. Compile time value calculation is an obvious area that is worth improving, and there are clearly some important untested code sections in ExprNodes.py: https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-py27-coverage/doclinks/1/Cython_Compiler_ExprNodes.html Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
On 26 April 2011 20:05, Robert Bradshaw wrote:
> On Tue, Apr 26, 2011 at 8:18 AM, mark florisson
> wrote:
>> On 26 April 2011 16:43, Stefan Behnel wrote:
>>> mark florisson, 26.04.2011 16:23:
I've been working a bit on fused types
(http://wiki.cython.org/enhancements/fusedtypes), and I've got it to
generate code for every permutation of specific types. Currently it
only works for cdef functions. Now in SimpleCallNode I'm trying to use
PyrexTypes.best_match() to find the function with the best signature,
but it doesn't seem to take care of coercions, e.g. it calls
'assignable_from' on the dst_type (e.g. char *), but for
BuiltinObjectType (a str) this returns false.
>>>
>>> Which is correct. "char*" cannot coerce from/to "str". It can coerce to
>>> "bytes", though.
>>>
>>> http://wiki.cython.org/enhancements/stringliterals
>>
>> Right, I see, so the thing is that I was using string literals which
>> should be inferred as the bytes type when they are assigned to a char
>> *. The thing is that because the type is fused, the argument may be
>> anything, so I was hoping best_match would figure it out for me.
>> Apparently it doesn't, and indeed, this example doesn't work:
>>
>> cdef extern from "Foo.h":
>> cdef cppclass Foo:
>> Foo(char *)
>> Foo(int)
>>
>> cdef char *foo = "foo"
>> cdef Foo* foo = new Foo("foo") # <- this doesn't work ("no suitable
>> method found")
>> cdef Foo* bar = new Foo(foo) # <- this works
>>
>> So that's pretty lame, I think I should fix that.
>
> Agreed.
>
Why is this the case,
don't calls to overloaded C++ methods need to dispatch properly here
also?
>>>
>>> If this doesn't work, I assume it just isn't implemented.
>>>
>>>
Other issues are public and api declarations. So should we support
that at all? We could define a macro that calls a function that does
the dispatch. So e.g. for this
ctypedef cython.fused_type(typeA, typeB) dtype
cdef func(dtype x):
...
we would get two generated functions, say, __pyx_typeA_func and
__pyx_typeB_func. So we could have a macro get_func(dtype) or
something that then substitutes __pyx_get_func(#dtype), where
__pyx_get_func returns the pointer to the right function based on the
type names. I'm not sure we should support it, right now I just put
the mangled names in the header. At least the cdef functions will be
sharable between Cython implementation files.
>>>
>>> I'm fine with explicitly forbidding this for now. It may eventually work for
>>> Python object types where we can properly dispatch, but it won't easily work
>>> for C types. It may work in C++, though.
>>>
>>
>> Ok, will do.
>
> For the moment, putting mangled names in the header should be fine. A
> macro might make sense in the long term.
>
> Somewhat orthogonal, it could makes sense to do some dispatching on
> type for cpdef functions.
>
I also noticed that for cdef functions with optional argument it gets
a struct as argument, but this struct doesn't seem to end up in the
header file when the function is declared public. I believe that also
the typedefs for ctypedef-ed things in the .pyx file don't make it
there when used to type a cdef function's arguments. Should that be
fixed?
>>>
>>> No, I think this should also become a compiler error. These functions are
>>> not meant to be called from C code. It's a Cython convenience feature. As
>>> long as it's not correctly supported on both ends of the publicly exported
>>> C-API, it's best to keep users from using it at all.
>>
>> Ok, I'll try to make Cython issue an error for these cases.
>
> +1
>
> - Robert
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
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. So I think it would be inconsistent to
suddenly start allowing comparison with 'is' and 'isinstance' and
such.
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?
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
mark florisson, 28.04.2011 21:48: 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. So I think it would be inconsistent to suddenly start allowing comparison with 'is' and 'isinstance' and such. 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's wrong with type() ? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
On 28 April 2011 21:58, Stefan Behnel wrote: > mark florisson, 28.04.2011 21:48: >> >> 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. So I think it would be inconsistent to >> suddenly start allowing comparison with 'is' and 'isinstance' and >> such. >> >> 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's wrong with type() ? > > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > When you call type you kind of expect it to call the Python builtin type(), which means it will coerce your C type to a Python object, on which it will call type(). So if you change those semantics suddenly for C types, I think we'd break people's code. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
On 28 April 2011 22:10, mark florisson wrote: > On 28 April 2011 21:58, Stefan Behnel wrote: >> mark florisson, 28.04.2011 21:48: >>> >>> 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. So I think it would be inconsistent to >>> suddenly start allowing comparison with 'is' and 'isinstance' and >>> such. >>> >>> 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's wrong with type() ? >> >> Stefan >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> > > When you call type you kind of expect it to call the Python builtin > type(), which means it will coerce your C type to a Python object, on > which it will call type(). So if you change those semantics suddenly > for C types, I think we'd break people's code. > Also, you'd want this to work for Python types too, for instance for two differently typed extension type attributes ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
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. > 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
Re: [Cython] Fused Types
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(). 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? 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
Re: [Cython] [cython-users] using generators
On Wed, Apr 27, 2011 at 11:42 PM, Stefan Behnel wrote: > Robert Bradshaw, 27.04.2011 22:41: >> >> On Wed, Apr 27, 2011 at 1:19 PM, Mad wrote: >>> >>> Hi list, >>> i just read, that generators are supported in cython 0.15 - great news >>> and brw, manny thanks. but is it somehow possible to use them with >>> cython 0.14 too? >>> It would be nice, if there's a patch (or the patch of 0.14 -> 0.15 >>> could be applied to the 0.14 source) to get them working, If this is >>> not possible, >> >> No, that's not possible--there's a lot that went on between here and >> there (it's not something you can just patch in). Any reason you're >> trying to stick with 0.14? >> >>> is 0.15 in a usable state? and how could i get it? >> >> It hasn't been released yet, and the development branch (on github) is >> relatively stable but not quite ready yet. As for the state of >> generators, Vitja and Stefan can comment more than I can, but there >> are still some corner cases with exception throwing that don't quite >> work like Python, and there's also a regression with respect to inline >> generators. I'm not sure if either of these is enough to be a blocker >> for a release. > > Don't think they are. As you said, the exception handling is for corner > cases (which exceptions should always be anyway) and I consider the > behaviour "close enough" now to not be a major issue. Vitja can comment on > this, too. The only case where I know that it currently diverges is > exception chaining in Python 3. And that should be fixable. > > Inline generators will require some work to become usable again. > Specifically, the expression scope that I had previously implemented for > comprehensions (and reused for generator expressions) doesn't work with the > then already created function scope of the generator. This needs to be fixed > somehow, either by moving the declarations over to the expression scope or > by directly using the function scope instead. In the latter case, it would > also be nice to merge this with the scoped comprehensions as well. > > So, agreed that these are regressions, but certainly less important than > getting generators and coroutines out in the wild. OK, I've added the inline generator tests to the bug list so we can see where we stand. I'd like to get Sage back up and compiling as well. Any thoughts on a release timeline? Any other known instabilities? - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
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. > 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? 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
Re: [Cython] Fused Types
On Thu, Apr 28, 2011 at 1:31 PM, 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(). 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 + func() and all instances of fused_type get specialized in the body. > 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. > 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
Re: [Cython] Fused Types
On Thu, Apr 28, 2011 at 2:29 PM, mark florisson wrote: > 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. Yes. We could consider supporting "typeof(x) is typeof(double)" or even "typeof(int*)" etc. as well to not tie ourselves to strings. Or perhaps some other syntax we haven't thought of. Alternatively, it would be nice if it involved the literal fused_type as that's what we're really branching on, e.g. ctypedef cython.fused_type(A, B) AorB cdef foo(AorB x): if AorB[A]: # or .A or something ... it's hard to come up with something that plays nicely with pointer types. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
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
Re: [Cython] Fused Types
On Thu, Apr 28, 2011 at 7:09 PM, Stefan Behnel 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. In terms of syntactically supporting pointers, we could either support "fused_type is typeof(void*)" or require typedefs for types not representable by an ExprNode. (This would make declaring fused types syntactically simpler as well...) I prefer the latter. - Robert > 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 > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
