PEP 3131: Supporting Non-ASCII Identifiers

[Marco Colombo]

On 13 Mag, 17:44, "Martin v. Löwis" <mar... at v.loewis.de> wrote:
> - should non-ASCII identifiers be supported? why?

Yes. For the same reason non-ASCII source files are supported.

> - would you use them if it was possible to do so? in what cases?

Yes. In the same cases I'd use:
1) non-English comments;
2) non-English string literals;
3) a source file that is already non-ASCII.

Not that I usually do that. I speak Italian natively, but write
programs with English identifiers, English comments, English output
most of the time and usually the encoding is ASCII. Yet we support
other encoding for the source file, that is non-ASCII comments,
literals, and so on. And non-ASCII means non-English.

There may be very few reasons to use non-ASCII, non-English words in a
python program, _anywhere_, but that's not the issue. We already
support people writing program with, say, Italian comments, Italian
words in string literals (natively utf-8 encoded, not with escape
sequences), no matter if they are right or wrong doing so. The
following is a valid source file:

  # coding=utf-8
  # stampa il nome della città
  citta = "Milano"
  print "Città:", citta

We support people doing that. While we're at it, why not support this
one as well:

  # coding=utf-8
  # stampa il nome della città
  città = "Milano"
  print "Città:", città

(for people unable to see it: there's a "LATIN SMALL LETTER A WITH
GRAVE" at the end of "citta" instead of a plain "LATIN SMALL LETTER A"
- in the second program, that's true for the identifier as well).

Question is: if we support the former (right or wrong, we do), what do
we loose in supporting the latter? Most arguments against this PEP I
saw here apply to both programs, I'd like to see one that applies only
to the second one.

.TM.