Greg Ewing, 25.11.2009 23:39:
> Stefan Behnel wrote:
>> Ah, right, that's due to the str/bytes/unicode separation in 0.12.
>
> Ah, I see. It's probably behaving as designed, then,
> because the user hasn't said that his str class is
> based on anything that would be compatible with a
> builtin str.
>
> I think the difference is that Cython has an internal
> notion of the builtin str class, whereas Pyrex
> doesn't -- to Pyrex, a Python string is just a
> generic Python object.
Yes, I know. Cython as departed from this a little lately, especially in 0.12.
I'm a big fan of having the compiler fail early if it detects something
that would lead to an error at runtime. Coercion between different string
types is an area where I think this is particularly helpful, but I think
the rules are a little too strict. Unknown/external/underdefined types must
always be allowed in assignments as the compiler can't know for sure if
they will work or not.
The only case where assignments between known distinct types work is when
the value is None. But even then, I don't see a use case for allowing this:
cdef list l = None
cdef str s = l
IMHO, if a user explicitly types a variable (which is absolutely optional
for Python types), he/she must be aware that this restricts its value set
and consequently its use. Disallowing the above (for cases where automatic
coercion is not clearly obvious) is something I would want Cython to do at
compile time, not runtime.
> If Cython does have a str type internally, it
> needs to be exposed so that users can use it or
> subclass from it without confusing the type
> checking.
Sure.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
