On Tue, Apr 26, 2011 at 8:18 AM, mark florisson <markflorisso...@gmail.com> wrote: > On 26 April 2011 16:43, Stefan Behnel <stefan...@behnel.de> 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
