On 11/24/17 11:41 AM, Skip Montanaro wrote:
Because if I already can't understand the words, it will be more useful
to me to be able to type them reliably at a keyboard, for replication,
search, discussion with others about the code, etc.
I am probably not alone in my Americo-centric world where I can't even
easily type accented Latin-1 characters. I happen to be using Linux as
I type this, but type at a Windows keyboard at work (ugh) and have
long been a user of Macs (still have one or two at home). Might the
problem be further multiplied by the number of different ways I have
of entering text? Would Emacs running on Linux, but displaying on
Windows be different than Chrome running directly on Linux? I will
make a wild-ass guess and suggest that maybe, just maybe, those three
major system types have different ways of typing accented characters.
Consequently, I've never even tried to learn any of them. On the rare
instance where I need to type an accented character, such as when
typing Marc-André Lemburg's name properly, I ask Google for "accented
e" and copy/paste an instance.
That's a PITA, but worth it on the few occasions where I need it
today. I suppose I would have to break down and learn how to properly
enter such text should I need to Romanized text which might contain
cedillas, accents and other diacritical marks...
This is all not to suggest the goal isn't worth striving for, just
that there exists a huge barrier - in the form of ASCII and its
limiting effect on computer keyboard entry - to attaining Unicode
identifier Nirvana. Perhaps for my next computer I should choose a
non-ASCII keyboard option when configuring it.
Skip
I find it it interesting that the primary reason to want to limit the
character set to ASCII is people thinking that it would make it hard for
*them* to read/use the code, but no thought about how much harder it
makes it on the original author/team to write code that is easily
understood by THEM. Yes, code intended to be used by the broad community
would be best to adhere to the community standard (and the community
style guide should, if it doesn't already, have a rule about this). Code
intended for internal usage is best to be as well understood by that
group as possible.
Some also bring up some of the issues with similar glyphs, as if we
don't already have issues with things like 0 and O, 1 and l and I
(depending on the font you use). This mostly comes down to
self-inflicted pain, which can mostly be relieved with a style rule to
avoid multi-language identifiers, perhaps checked with a special
'linter'. Since Python is white space sensitive, we already have the
issue with the distinction between space and tab, which isn't normally
obvious in many text editors (Though I suspect many Python programmers
have their editors configured to largely avoid the issue).
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
