Lisandro Dalcin, 06.09.2010 21:59:
> On 6 September 2010 16:52, Stefan Behnel wrote:
>> Dag Sverre Seljebotn, 06.09.2010 21:36:
>>> Stefan Behnel wrote:
>>>> Dag Sverre Seljebotn, 06.09.2010 20:30:
>>>>> 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.
>>>>
>>>> Well, then why not keep it the way it was before and *always* require a 'b'
>>>> prefix in front of char* literals when unicode_literals is enabled? After
>>>> all, it's an explicit option, so users who want to enable it can be
>>>> required to adapt their code accordingly.
>>>>
>>> If this can get any momentum, I'm all for it (I was dismissing it when
>>> thinking about it because I thought it would meet opposition
>>> everywhere). It doesn't really make sense to assign unicode literals to
>>> char* in the first place to me, and with -3 or unicode_literals you're
>>> pretty much asking for having to do such a change.
>>
>> It's certainly the cleanest way to handle this. Lisandro didn't like it
>> when he stumbled over it, because it means that he actually has to change
>> his code. It's easy to do that, given that Cython reports all such places
>> with a compile error. It's just cumbersome. Maybe a Cython specific 2to3
>> tool could help.
>
> Stefan, I do not have any problem about changing my code... What I
> really like and want is to have a single Cython source that generated
> C-code being able to run in Python-2 and Python-3 runtime... Because
> of this, In many cases I have to use unprefixed (but pure ASCII)
> string literals and use the 'str' type, expecting that to become
> PyUnicode on Py3 and PyString under Py2.

That's not the problem we are discussing here, though. This thread is about 
*C string* literals, which should or should not change due to 
unicode_literals being enabled. That's the question.

I think it makes sense to keep the two discussions separate.

Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to