PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

sjdevnull at yahoo.com a écrit :
> Christophe wrote:
>> sjdevnull at yahoo.com a ecrit :
>>> Steven D'Aprano wrote:
>>>> I would find it useful to be able to use non-ASCII characters for heavily
>>>> mathematical programs. There would be a closer correspondence between the
>>>> code and the mathematical equations if one could write D(u*p) instead of
>>>> delta(mu*pi).
>>> Just as one risk here:
>>> When reading the above on Google groups, it showed up as "if one could
>>> write ?(u*p)..."
>>> When quoting it for response, it showed up as "could write D(u*p)".
>>>
>>> I'm sure that the symbol you used was neither a capital letter d nor a
>>> question mark.
>>>
>>> Using identifiers that are so prone to corruption when posting in a
>>> rather popular forum seems dangerous to me--and I'd guess that a lot
>>> of source code highlighters, email lists, etc have similar problems.
>>> I'd even be surprised if some programming tools didn't have similar
>>> problems.
>> So, it was google groups that continuously corrupted the good UTF-8
>> posts by force converting them to ISO-8859-1?
>>
>> Of course, there's also the possibility that it is a problem on *your*
>> side
> 
> Well, that's part of the point isn't it?  It seems incredibly naive to
> me to think that you could use whatever symbol was intended and have
> it show up, and the "well fix your machine!" argument doesn't fly.  A
> lot of the time programmers have to look at stack traces on end-user's
> machines (whatever they may be) to help debug.  They have to look at
> code on the (GUI-less) production servers over a terminal link.  They
> have to use all kinds of environments where they can't install the
> latest and greatest fonts.  Promoting code that becomes very hard to
> read and debug in real situations seems like a sound negative to me.

Who displays stack frames? Your code. Whose code includes unicode 
identifiers? Your code. Whose fault is it to create a stack trace 
display procedure that cannot handle unicode? You. Even if you don't 
make use of them, you still have to fix the stack trace display 
procedure because the exception error message can include unicode text 
*today*

You should know that displaying and editing UTF-8 text as if it was 
latin-1 works very very well.

Also, Terminals have support for UTF-8 encodings already. Or you could 
always use kate+fish to edit your script on the distant server without 
such problems (fish is a KDE protocol used to access a computer with ssh 
as if it was a hard disk and kate is the standard text/code editor) It's 
a matter of tools.