Robert Bradshaw wrote:
> On Nov 27, 2009, at 10:52 PM, Stefan Behnel wrote:
>> Currently, coercion from char*/bytes to unicode is an explicit step
>> that is
>> easy to do via
>>
>> cdef char* s = ...
>> u = s[:length].decode('UTF-8')
>>
>> in 0.12. See
>>
>> http://trac.cython.org/cython_trac/ticket/436
>
> That is an improvement, though still a lot more baggage than
>
> cdef char* s = ...
> u = s
Hmm. Seeing it in action makes me worry even more. I'm leaning towards
-1 for the whole proposal now.
In Python "u = s" always mean a strict transfer of reference. In Cython
we diverge from this (apart from raising exceptions on mismatch) in some
places:
a) When converting intrensic types. However these are always immutable
in Python and so the semantic mismatch isn't there.
b) Structs
c) When converting char*<->bytes? (If a copy is made, otherwise it can
be considered similar with Python. I'm not sure what the case is.).
Making "u = s" mean more than a pure transfer of reference/copy of
immutable object makes problems for both pure Python mode and
possibility of type inference. I believe it contradicts the direction
we've gone in -- that static types should be as optional as we can
possibly make them, instead, it is proposed that "u = s" is overloaded
to mean encoding conversion, which is something quite different from an
assignment.
I believe this contradicts the Pythonic philosophy of being explicit
(where even "self" is passed explicitly...).
One solution around this would be to create a new, Cython-specific
string class which constitutes a view on a char*, rather than a copy.
Views are fine (as they are semantically similar to a pure reference
assignment "u = s").
Is proper string handling creating big problems in Sage, since the
question keeps coming up? I just don't mentally associate char* with
strings at all and thus didn't ever think about this as a problem...I
don't know why one wouldn't want to call encode/decode explicitly if
only to make better self-documenting code about what is going on.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
