On 9 February 2013 03:44, Stefan Behnel <stefan...@behnel.de> wrote: > Hi, > > I noticed that Cython currently fails to do this: > > cdef int (*int_abs)(int x) > cdef object py_abs > py_abs = int_abs = abs > > Here, abs() is an overloaded function with a couple of C signatures (fabs() > and friends) and a Python signature (the builtin). While there is code in > NameNode.coerce_to() that figures out that the RHS can be replaced by the > Python builtin, the same is lacking for the general case of overloaded > entries. > > While working on fixing this problem (and after turning ProxyNode into an > actual node proxy when it comes to coercion), I thought it would be a good > idea to make NameNode generally aware of alternative entries and just build > a new NameNode with the right entry in its coerce_to() method. Then I > noticed that the generic coerce_to() contains this code: > > if src_type.is_fused or dst_type.is_fused: > # See if we are coercing a fused function to a pointer to a > # specialized function > if (src_type.is_cfunction and not dst_type.is_fused and > dst_type.is_ptr and dst_type.base_type.is_cfunction): > > dst_type = dst_type.base_type > for signature in src_type.get_all_specialized_function_types(): > if signature.same_as(dst_type): > src.type = signature > src.entry = src.type.entry > src.entry.used = True > return self > > This is essentially the same idea, just done a bit differently (with the > drawback that it modifies the node in place, which coerce_to() must *never* > do). > > So, two questions: > > 1) why is the above code in the generic coerce_to() method and not in > NameNode? It doesn't seem to do anything sensible for most other nodes, > potentially not even AttributeNode. And it might fail silently when working > on things like CloneNode that don't care about entries. Are there other > nodes where it does what it should?
I think it works for names and attributes, it allows you to retrieve a specialized version of the fused c(p)def functions and methods. > 2) couldn't fused functions be mapped to a set of overloaded functions > (read: entries) before hand, instead of special casing both in places like > this? Quite possibly, although I'd have to dig in the codebase some more to verify that. You can give it a try, it'd be nice to unify the approaches under the same model. > 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
