Robert Bradshaw wrote: > On Sep 14, 2009, at 11:48 AM, Lisandro Dalcin wrote: >> On Mon, Sep 14, 2009 at 2:36 PM, Robert Bradshaw wrote: >>>> Lisandro Dalcin wrote: >>>>> I'm inclined for a warning... and that warning would not be >>>>> generated >>>>> in this case: "cdef char*cs = <bytes>s" , right? >>> That could be bad, <bytes>s doesn't actually do a typecheck, >>> especially if the bytes -> char* is eventually optimized. One should >>> do <bytes?>s or <object>s (neither of which generate a warning). >> Of course, <bytes> is as dangerous as any <some_py_type> cast (and >> these casts defaulting to no-typecheck are the root of the evil)... > > I was considering <type!> for a no-typecheck cast at one point, but > changing the default to do typechecking is super backwards incompatible.
I'm ok with a runtime safe <type?> cast. After all, casting between Python objects is still a rather rare thing, and I only really do it when I know the exact type and Cython will clearly drop loads of generic code for it. >> Still, as <some_py_type> casts are "blindly" honoured, I'm not sure if >> we should special case this usage ... > > No, I don't think we should special case it--I'm saying that we > shouldn't encourage this as it could produce a hard crash if s is not > bytes, e.g. input from in Py3. How hard it would crash depends on our optimisations, but I agree otherwise. See my change in the CEP. >> Perhaps it is time to generate Cython compile-time warning when >> calling with an untyped arg value? Again, an explicit cast would >> suppress the warning... >> >> I mean, suppose this code: >> >> cdef void foo(tuple t): # REMEMBER!!, foo() does not typecheck that >> "t" is actually a tuple!!! >> pass >> >> cdef object a = 1 >> foo(a) >> >> cdef list b = [1] >> foo(b) >> >> cdef tuple c = (1,) >> foo(c) >> >> 1) When calling foo(a), we could emit a compile-time warning and >> generate C code with runtime type-check... What's the point of duck >> typing here iff foo() actually requires a tuple? > > We don't want to generate so many warnings they become useless, I > personally wouldn't want that on by default. It's nice because a lot > of the inputs, return results, etc. are not typed, e.g. I can do foo > (bar(x)) where bar is any old Python function. -1 on "untyped" warnings. We still /discourage/ explicit typing in most cases. >> 2) When calling foo(b), we could generate compile-time ERROR... What's >> the point of letting this Cython-compile silently and making it fail >> as runtime (like currently happens) ? > > Yes, that would probably be a good idea. Note that the value might be None, which might still pass. Although if the user knows that the value is None, she/he'd probably also spell it that way, so an error should be ok. After all, in the current state, the user most likely provided the type explicitly anyway. BTW, for the specific case of list/tuple, there's a PyList_AsTuple() function and the PySequence_List/Tuple() functions that might become useful - although I'm certainly not saying we should do the required copying automatically behind the back of the user. >> 3) When calling foo(c), no warnigns and no C runtime type-check (as >> currently is being done) > > Yep. Sure. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
