On Sep 14, 2009, at 11:48 AM, Lisandro Dalcin wrote: > On Mon, Sep 14, 2009 at 2:36 PM, Robert Bradshaw > <[email protected]> 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. > 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. >>>>> BTW, we shouldn't forget to adapt the .pxd files in Cython/ >>>>> Includes >>>>> accordingly, so that they return either "bytes" or "unicode", but >>>>> *never* >>>>> "str" (or "object", if we know it's a string type). >>>> >>>> Could you point to a couple of the C-API calls you are talking >>>> about? >>> >>> Things like the encoding functions, for example, that convert >>> between bytes >>> and unicode. Using str here would be wrong. >>> >>> Plus, changing the argument/return value types from "object" to the >>> right >>> types will allow Cython to do actual type checking. >> >> Often the type checking will be redundant with the type checking that >> happens inside the method, so I'm not so sure this is a good idea. >> > > 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. > 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. > 3) When calling foo(c), no warnigns and no C runtime type-check (as > currently is being done) Yep. > BTW, perhaps all this stuff is important enough as to start a new > thread? Done :) - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
