On Sep 15, 2009, at 11:13 AM, Dag Sverre Seljebotn wrote: > Lisandro Dalcin wrote: >> On Tue, Sep 15, 2009 at 3:19 AM, Stefan Behnel >> <[email protected]> wrote: >>>>> 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. >>> >> >> Final note: cdef functions with no argument typecheck at all are as >> dangerous as Fortran 77... IMHO, Cython should do better, just >> because >> Python/Cython users are not real programmers ;-) ... >> >> But the current status is far from optimal... cdef functions do >> not do >> internally any typecheck on typed arguments (for performance >> reasons?), then you can call it with anything, and you can easily >> end-up with a segfault... > > This got confusing to me. I always had the impression that: > > a) def foo(MyType arg): ... > > means that the foo function itself checks the type on entry. > > b) cdef foo(MyType arg): ... > > means that foo does not check the type, but the caller does! > (Except, of > course, if the caller already know the type, which is a useful > optimization.) > > Is this understanding (of current behaviour) true or false?
That is exactly what happens, and is as it should be. This is an interesting asymmetry between cdef and def functions that I don't think it pointed out clearly anywhere. [...] >> In short, I think that moving/enforcing type-checks from >> Python-runtime to Cython-compile-time is a very good deal... Far >> better to get a complain from Cython, before you release your code, >> than a nasty, embarrassing Python exception when end-users try your >> code... I know, unittesting should catch these problems, but >> honestly... how many codes out there have 100% code coverage? > > -1. This thinking is a dangerous slope. Where do you stop? Why > would one > stop short of Java or C++ or Haskell? They all have different fully > typed systems which can help in *some* situations, but then the whole > language is designed around it. > > Python is just not designed for it. If we try to use types to > "encourage > good programming practice" then we essentially need to develop a new > language from ground up, which may or may not look like Python. I > don't > have the time for that, and wouldn't use the result (I'd rather learn > myself Haskell to be honest). > > I even had a seperate slide in my SciPy 09 presentation telling people > that static type checking (as a programming model) was not a valid > usecase for Cython; "Cython is typed because it has to, not because it > wants to." :-) Well said. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
