On Mon, Sep 6, 2010 at 11:30 AM, Dag Sverre Seljebotn
<[email protected]> wrote:
> Stefan Behnel wrote:
>> Robert Bradshaw, 06.09.2010 19:01:
>>
>>> On Mon, Sep 6, 2010 at 9:36 AM, Dag Sverre Seljebotn
>>>
>>>> I don't understand this suggestion. What happens in each of these cases,
>>>> for different settings of "from __future__ import unicode_literals"?
>>>>
>>>> cdef char* x1 = 'abc\u0001'
>>>>
>>
>> As I said in my other mail, I don't think anyone would use the above in
>> real code. The alternative below is just too obvious and simple.
>>
>>
>>
>>>> cdef char* x2 = 'abc\x01'
>>>>
>>> from __future__ import unicode_literals (or -3)
>>>
>>> len(x1) == 4
>>> len(x2) == 4
>>>
>>> Otherwise
>>>
>>> len(x1) == 9
>>> len(x2) == 4
>>>
>>
>> Hmm, now *that* looks unexpected to me.
>>
>> The way I see it, a C string is the
>> C equivalent of a Python byte string and should always and predictably
>> behave like a Python byte string, regardless of the way Python object
>> literals are handled.
>
> While the "cdef char*" case isn't that horrible,
>
> f('abc\x01')
>
> is. Imagine throwing in a type in the signature of f and then get
> different data in.
>
> I really, really don't like having the value of a literal depend on type
> of the variable it gets assigned to (I know, I know about ints and so
> on, but let's try to keep the number of instances down).
+1. This is the main reason I'm arguing my point. Literals should not
be re-interpreted based on context.
> My vote is for identifying a set of completely safe strings (no \x or
> \u, ASCII-only) that is the same regardless of any setting, and allow
> that. Anything else, demand a b'' prefix to assign to a char*. Putting
> in a b'' isn't THAT hard.
Sure. Many (most) libraries take char* for string values. I want to
avoid requiting special incantations (not that the 'b' is hard, but
one needs to know it) to write, e.g,
printf("Hello World\n")
Anything non-ascii, well, it's reasonable to force users to think
about bytes vs. strings, encodings, etc.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
