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?

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?

Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Reply via email to