On 11/23/17 2:46 PM, Thomas Jollans wrote:
On 23/11/17 19:42, Mikhail V wrote:
I mean for a real practical situation - for example for an average
Python programmer or someone who seeks a programmer job.
And who does not have a 500-key keyboard,
I don't think it's too much to ask for a programmer to have the
technology and expertise necessary to type their own language in its
proper alphabet.
My personal feeling is that the language needs to be fully usable with
just ASCII, so the - character (HYPHEN/MINUS) is the
subtraction/negation operator, not an in-name hyphen. This also means
the main library should use just the ASCII character set.
I do also realize that it could be very useful for programmers who are
programming with other languages as their native, to be able to use
words in their native language for their own symbols, and thus useful to
use their own character sets. Yes, doing so may add difficulty to the
programmers, as they may need to be switching keyboard layouts
(especially if not using a LATIN based language), but that is THEIR
decision to do so. It also may make it harder for outside programmers to
hep, but again, that is the teams decision to make.
The Unicode Standard provides a fairly good classification of the
characters, and it would make sense to define that an character that is
defined as a 'Letter' or a 'Number', and some classes of Punctuation
(connector and dash) be allowed in identifiers.
Fully implementing may be more complicated than it is worth. An interim
simple solution would be just allow ALL (or maybe most, excluding a
limited number of obvious exceptions) of the characters above the ASCII
set, with a warning that only those classified as above are promised to
remain valid, and that other characters, while currently not generating
a syntax error, may do so in the future. It should also be stated that
while currently no character normalization is being done, it may be
added in the future, so identifiers that differ only by code point
sequences that are defined as being equivalent, might in the future not
be distinct.
Since my native language is English, this isn't that important to me,
but I do see it as being useful to others with different native tongues.
The simple implementation shouldn't be that hard, you can just allow
character codes 0x80 and above as being acceptable in identifiers, with
the documented warning that the current implementation allows some forms
that may generate errors in the future. If enough interest is shown,
adding better classification shouldn't be that hard.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
