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?
Whatever the <cast operator> does is something else entirely and much
less important IMO.
> I understand that we /discourage/ explicit typing and agree with that.
> However, I think that if a user INSIST in using explicit typing for
> some args in a cdef function, she should be prepared to make sure that
> when calling that function, the argument have a proper, known type at
> Cython compile-time... In fact, this is a way to discourage even more
> explicit typing... And this will help catch nasty bugs when explicit
> typing is used.
I think the behaviour described above is perfect, that is: If you do
cdef foo(MyType arg): ...
def caller(x):
foo(x)
then "caller" has code inserted to check that x is indeed MyType before
passing it. It is exactly the same case as
cdef MyType y = x
However, of course, if you do
def other_caller(MyType x):
print "entered"
foo(x)
then there is (of course) no need to do another type check beyond the
one that is done before "entered" is printed.
> 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." :-)
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
