Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Richard Damon]

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