On 13 Mag, 17:44, "Martin v. Löwis" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
