Hi Robert,
Robert Bradshaw wrote:
> On Sep 14, 2009, at 12:05 PM, Stefan Behnel wrote:
>>>>> cdef str s = "some string"
>>>>> cdef char* cs = s
>>>>>
>> I don't see a reason to
>> special case some casts while we already allow all that dangerous C
>> stuff.
>> If nothing else, a cast is a clear way to say "I know better!". And
>> if you
>> actually do not know better, you'll see where that gets you. Not
>> Cython's problem.
>
> Yes, as I said I was just saying that we shouldn't encourage *this*
> solution, as it doesn't do type checking.
We can always try to improve the error message. Users who are unaware of
the resulting problems will first try
cdef char* cs = s
and only when Cython barfs at them they'd consider casting. But if Cython
says "Coercing str to char* is not portable to Python 3, please use the
bytes type instead", I think that might do the trick.
I added that to the CEP.
>>>> 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.
>> I meant compile time type checking, which won't hurt performance
>> but helps
>> in making the C-API safer and also allows Cython to do some
>> optimisations.
>
> Sometimes. For example, PyUnicode_GetSize in principle take a unicode
> object, but is only typed to take a object. It performs its own
> typecheck, so we should just define it as taking an object and not do
> the redundant type check ourselves.
Right, input parameters are a different thing. Currently, we only do type
checks for C-API calls we inject internally. There definitely shouldn't be
any type checks in runtime code for C-API calls, and I agree that they make
little sense at compile time as well. I'm more concerned about return
types, which are almost always known in the C-API.
>> For example, this:
>>
>> cdef unicode u = some_unicode_string
>> s = u.encode('UTF-8')
>>
>> will now result in a straight C call to the UTF-8 encoder, instead of
>> looking up the method, calling it, and having it look up the codec
>> internally. I find that pretty cool.
>
> Hmm, not for me (at least not in the -devel branch), but I could see
> this being very nice.
Yes, cython-unstable has quite some improvements in that regard, but I
don't think backporting them is really worth bothering if we get out 0.12
any soon.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev