PEP 3131: Supporting Non-ASCII Identifiers

[sjdevnull at yahoo.com]

Christophe wrote:
> sjdevnull at yahoo.com a ecrit :
> > 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.

Thanks but no--I work with a _lot_ of code I didn't write, and looking
through stack traces from 3rd party packages is not uncommon.

And I'm often not creating a stack trace procedure, I'm using the
built-in python procedure.

And I'm often dealing with mailing lists, Usenet, etc where I don't
know ahead of time what the other end's display capabilities are, how
to fix them if they don't display what I'm trying to send, whether
intervening systems will mangle things, etc.

> 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*

It can, but having identifiers in portable characters at least allows
some ability to navigate the code.  Display of strings is safe by
default anyway, as they can contain all sorts of data.

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

Given that we've already seen one (fairly simple) character posted in
this thread that displayed differently in the HTML view than in the
edit--and neither place as the symbol originally intended--I'm going
to reserve judgement on this statement.   I don't know whether the
problem was with Google, my browser, or something else, but I do know
that it made interchange of information difficult and that I'm using a
fairly recent (within the last 3 years) out-of-the-box setup.

> 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.

You don't always get to pick your tools.  It's very nice to have
things work with standard setups, be they brand new Windows boxes or
the c. 1993 mail server in the office or your wife's handheld that
you've grabbed to help do emergency troubleshooting from your vacation
or whatever.