Re: Increasing the diversity of people who write Python

[Marko Rauhamaa]

Christian Gollwitzer :
> Am 28.11.17 um 20:24 schrieb wxjmfa...@gmail.com:
>> 00FF LETTRE MINUSCULE LATINE Y TRÉMA
>
> WTF is this? The character is correctly called
> "LATIN SMALL LETTER Y WITH DIAERESIS". There is no non-ASCII character
> in this description. Of course, if I translated the Unicode mapping to
> Polish, there would be an even larger number of non-ASCII letters -
> but what good would that be for an IT standard, if the identifiers
> were written in different languages?

The ISO/IEC standards are issued in many languages. French and English
have the strongest footing; French is maybe slightly more primary than
English.

http://www.iec.ch/tcnews/restricted/2009june/Directives-IECSup-Ed5-1.pdf>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Christian Gollwitzer]

Am 28.11.17 um 20:24 schrieb wxjmfa...@gmail.com:

Le mardi 28 novembre 2017 04:44:51 UTC+1, Rustom Mody a écrit :

...

Unicode codepoint names are (evidently) ALLCAPS-ASCII



Are you sure ? ;-)


; Standard Unicode 10.0.0 ou
;   Norme internationale ISO/CEI 10646:2017

...

00FFLETTRE MINUSCULE LATINE Y TRÉMA


WTF is this? The character is correctly called
"LATIN SMALL LETTER Y WITH DIAERESIS". There is no non-ASCII character 
in this description. Of course, if I translated the Unicode mapping to 
Polish, there would be an even larger number of non-ASCII letters - but 
what good would that be for an IT standard, if the identifiers were 
written in different languages?


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Chris Angelico]

On Wed, Nov 29, 2017 at 3:44 PM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>>
>> Heh, you mean the term "Windows key"? It's not appropriate on
>> keyboards that don't have an actual Windows logo on it. There are
>> other names for it, but I figured the easiest way was to describe its
>> location :D
>
>
> That doesn't work for all keyboards, though. The one I'm using
> right now doesn't have any key between the left alt and left
> control keys. (It does have another key just to the right of
> the alt key that might have roughly analogous functionality in
> some circumstances.)
>

Yeah, which is why it's completely configurable. I was just saying
which key *I* use, on my particular layout.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Gregory Ewing]

Chris Angelico wrote:

Heh, you mean the term "Windows key"? It's not appropriate on
keyboards that don't have an actual Windows logo on it. There are
other names for it, but I figured the easiest way was to describe its
location :D


That doesn't work for all keyboards, though. The one I'm using
right now doesn't have any key between the left alt and left
control keys. (It does have another key just to the right of
the alt key that might have roughly analogous functionality in
some circumstances.)

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas Jollans]

On 2017-11-24 17:41, Skip Montanaro wrote:
> Perhaps for my next computer I should choose a
> non-ASCII keyboard option when configuring it.
> 
> Skip
> 

I'm quite fond of the US international keyboard layout. It lets you type
most Latin-lettered languages with relative ease (including, obviously,
the few accented letters used in English). It's conveniently available
(and almost identical) on all (major) operating systems, but alas
Windows only has a dead-keys variant built in. (But I believe you can
download a no-dead-keys variant somewhere)

It's nice because (with a no-dead-keys version) unless you press AltGr,
everything's the same as with a traditional US keyboard (which is not
entirely suitable for the English language on its own).

On Windows machines I only use occasionally (and may not have admin
rights on) I tend to set up both "US" and "US international" keyboard
layouts and switch between them depending on what I'm typing. It's not
ideal, but it's better than either programming being a pain in the arse
(with all the dead keys) or not being able to type natural-language
words properly.

-- 
Thomas Jollans
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Tim Golden]

On 28/11/2017 08:41, Paul Moore wrote:

On 27 November 2017 at 19:05, Paul Moore  wrote:

On 27 November 2017 at 18:13, Skip Montanaro  wrote:

If you have a Windows key, you can assign it to be
the Compose key.


Would this be true on a machine running Windows? My work environment
has me developing on Linux, with a Windows desktop. It's not clear to
me that any sort of xmodmap shennanigans would work. Won't Windows
itself always gobble up that key?


Programs can access the Windows key. IIRC, there is a utility that
provides compose-key functionality on Windows. I can't recall the name
right now and it's on my other PC, not this one, but I'll try to
remember to post the name tomorrow...


WinCompose was the program - https://github.com/samhocevar/wincompose


And, if you wanted a Python-y solution:

http://timgolden.me.uk/python/win32_how_do_i/catch_system_wide_hotkeys.html

TJG
--
https://mail.python.org/mailman/listinfo/python-list

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

[Paul Moore]

On 27 November 2017 at 19:05, Paul Moore  wrote:
> On 27 November 2017 at 18:13, Skip Montanaro  wrote:
>>> If you have a Windows key, you can assign it to be
>>> the Compose key.
>>
>> Would this be true on a machine running Windows? My work environment
>> has me developing on Linux, with a Windows desktop. It's not clear to
>> me that any sort of xmodmap shennanigans would work. Won't Windows
>> itself always gobble up that key?
>
> Programs can access the Windows key. IIRC, there is a utility that
> provides compose-key functionality on Windows. I can't recall the name
> right now and it's on my other PC, not this one, but I'll try to
> remember to post the name tomorrow...

WinCompose was the program - https://github.com/samhocevar/wincompose

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Rustom Mody]

On Monday, November 27, 2017 at 10:49:35 PM UTC+5:30, Skip Montanaro wrote:
> > I strongly suspect that any recent emacs will have M-x insert-char
> > (earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats 
> > clunky)
> > which will accept at the minibuffer input
> 
> I tried C-x 8 e acute TAB
> 
> and was prompted with "E-acute". I don't know why it would have
> capitalized the "e". 

Unicode codepoint names are (evidently) ALLCAPS-ASCII

Still, I plowed ahead and hit RET
> 
> which yielded an "Invalid character" message in the minibuffer.

Unicode is a million+ codepoints
Hundred thousand+ of which are assigned
This means that (as an analogy) emacs is fishing around in a 100,000 line file
which contains lines like
LATIN SMALL LETTER A:a:0x61
LATIN CAPITAL LETTER A:A:0x41
DIGIT ONE:1:0x31
... 100,000 such lines… one of which is
LATIN SMALL LETTER E WITH ACUTE:é:0xe9

[Just now fishing around I find its worse than that C-u C-x = tells me:

  character: é (displayed as é) (codepoint 233, #o351, #xe9)
  name: LATIN SMALL LETTER E WITH ACUTE
  old-name: LATIN SMALL LETTER E ACUTE
  general-category: Ll (Letter, Lowercase)

So those hundred thousand chars can have multiple names!!
And that constitutes the search space
]

So now coming to your attempt:

[ Writing this mail, Ive finally done:
(global-set-key (kbd "") 'insert-char)
which allows me to use F9 instead of the clunky C-x 8 RET
I'll assume that binding following
]

If I type
F9*e acuteTAB
I get 121 possibilities:

CANADIAN SYLLABICS FINAL DOUBLE ACUTE (ᐥ)
COMBINING DOTTED ACUTE ACCENT (᷁)
COMBINING DOUBLE ACUTE ACCENT (̋)
CYRILLIC CAPITAL LETTER U WITH DOUBLE ACUTE (Ӳ)
CYRILLIC SMALL LETTER U WITH DOUBLE ACUTE (ӳ)
DEVANAGARI ACUTE ACCENT (॔) DOUBLE ACUTE ACCENT (˝)
GREEK UPSILON WITH ACUTE AND HOOK SYMBOL (ϓ)
LATIN CAPITAL LETTER A ACUTE (Á)
LATIN CAPITAL LETTER A WITH ACUTE (Á)
LATIN CAPITAL LETTER A WITH BREVE AND ACUTE (Ắ)
LATIN CAPITAL LETTER A WITH CIRCUMFLEX AND ACUTE (Ấ)
LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE (Ǻ)
LATIN CAPITAL LETTER AE WITH ACUTE (Ǽ)
LATIN CAPITAL LETTER C ACUTE (Ć)
LATIN CAPITAL LETTER C WITH ACUTE (Ć)
LATIN CAPITAL LETTER C WITH CEDILLA AND ACUTE (Ḉ)
LATIN CAPITAL LETTER E ACUTE (É)
LATIN CAPITAL LETTER E WITH ACUTE (É)
LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE (Ế)
LATIN CAPITAL LETTER E WITH MACRON AND ACUTE (Ḗ)
LATIN CAPITAL LETTER G WITH ACUTE (Ǵ)
LATIN CAPITAL LETTER I ACUTE (Í)
LATIN CAPITAL LETTER I WITH ACUTE (Í)
LATIN CAPITAL LETTER I WITH DIAERESIS AND ACUTE (Ḯ)
LATIN CAPITAL LETTER K WITH ACUTE (Ḱ)
LATIN CAPITAL LETTER L ACUTE (Ĺ)
LATIN CAPITAL LETTER L WITH ACUTE (Ĺ)
LATIN CAPITAL LETTER M WITH ACUTE (Ḿ)
LATIN CAPITAL LETTER N ACUTE (Ń)
LATIN CAPITAL LETTER N WITH ACUTE (Ń)
LATIN CAPITAL LETTER O ACUTE (Ó)
LATIN CAPITAL LETTER O DOUBLE ACUTE (Ő)
LATIN CAPITAL LETTER O WITH ACUTE (Ó)
LATIN CAPITAL LETTER O WITH CIRCUMFLEX AND ACUTE (Ố)
LATIN CAPITAL LETTER O WITH DOUBLE ACUTE (Ő)
LATIN CAPITAL LETTER O WITH HORN AND ACUTE (Ớ)
LATIN CAPITAL LETTER O WITH MACRON AND ACUTE (Ṓ)
LATIN CAPITAL LETTER O WITH STROKE AND ACUTE (Ǿ)
LATIN CAPITAL LETTER O WITH TILDE AND ACUTE (Ṍ)
LATIN CAPITAL LETTER P WITH ACUTE (Ṕ)
LATIN CAPITAL LETTER R ACUTE (Ŕ)
LATIN CAPITAL LETTER R WITH ACUTE (Ŕ)
LATIN CAPITAL LETTER S ACUTE (Ś)
LATIN CAPITAL LETTER S WITH ACUTE (Ś)
LATIN CAPITAL LETTER S WITH ACUTE AND DOT ABOVE (Ṥ)
LATIN CAPITAL LETTER U ACUTE (Ú)
LATIN CAPITAL LETTER U DIAERESIS ACUTE (Ǘ)
LATIN CAPITAL LETTER U DOUBLE ACUTE (Ű)
LATIN CAPITAL LETTER U WITH ACUTE (Ú)
LATIN CAPITAL LETTER U WITH DIAERESIS AND ACUTE (Ǘ)
LATIN CAPITAL LETTER U WITH DOUBLE ACUTE (Ű)
LATIN CAPITAL LETTER U WITH HORN AND ACUTE (Ứ)
LATIN CAPITAL LETTER U WITH TILDE AND ACUTE (Ṹ)
LATIN CAPITAL LETTER W WITH ACUTE (Ẃ)
LATIN CAPITAL LETTER Y ACUTE (Ý)
LATIN CAPITAL LETTER Y WITH ACUTE (Ý)
LATIN CAPITAL LETTER Z ACUTE (Ź)
LATIN CAPITAL LETTER Z WITH ACUTE (Ź)
LATIN SMALL LETTER A ACUTE (á)
LATIN SMALL LETTER A WITH ACUTE (á)
LATIN SMALL LETTER A WITH BREVE AND ACUTE (ắ)
LATIN SMALL LETTER A WITH CIRCUMFLEX AND ACUTE (ấ)
LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE (ǻ)
LATIN SMALL LETTER AE WITH ACUTE (ǽ)
LATIN SMALL LETTER C ACUTE (ć)
LATIN SMALL LETTER C WITH ACUTE (ć)
LATIN SMALL LETTER C WITH CEDILLA AND ACUTE (ḉ)
LATIN SMALL LETTER E ACUTE (é)
LATIN SMALL LETTER E WITH ACUTE (é)
LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE (ế)
LATIN SMALL LETTER E WITH MACRON AND ACUTE (ḗ)
LATIN SMALL LETTER G WITH ACUTE (ǵ)
LATIN SMALL LETTER I ACUTE (í)
LATIN SMALL LETTER I WITH ACUTE (í)
LATIN SMALL LETTER I WITH DIAERESIS AND ACUTE (ḯ)
LATIN SMALL LETTER K WITH ACUTE (ḱ)
LATIN SMALL LETTER L ACUTE (ĺ)
LATIN SMALL LETTER L WITH ACUTE (ĺ)
LATIN SMALL LETTER M WITH ACUTE (ḿ)
LATIN SMALL LETTER N ACUTE (ń)
LATIN SMALL LETTER N WITH ACUTE (ń)
LATIN SMALL LETTER O ACUTE (ó)
LATIN SMALL LETTER O DOUBLE ACUTE (ő)
LATIN SMALL LETTER O WITH ACUTE (ó)
LATIN SMALL LETTER O WITH CIRCUMFLEX AND ACUTE (ố)
LATIN SMALL LETTER O WITH DOUBLE ACUTE 

Re: Increasing the diversity of people who write Python

[Mikhail V]

On Mon, Nov 27, 2017 at 8:09 PM, Alexandre Brault  wrote:
> A quick Google search turned up WinCompose. It defaults to Right-Alt for
> its compose key, but that's configurable
>
> On 2017-11-27 02:05 PM, Paul Moore wrote:
>> On 27 November 2017 at 18:13, Skip Montanaro  
>> wrote:
 If you have a Windows key, you can assign it to be
 the Compose key.
>>> Would this be true on a machine running Windows? My work environment
>>> has me developing on Linux, with a Windows desktop. It's not clear to
>>> me that any sort of xmodmap shennanigans would work. Won't Windows
>>> itself always gobble up that key?
>> Programs can access the Windows key. IIRC, there is a utility that
>> provides compose-key functionality on Windows. I can't recall the name
>> right now and it's on my other PC, not this one, but I'll try to
>> remember to post the name tomorrow...
>>
>> Paul


On Windows people usually use AHK (Autohotkey).
It is a programming language, so you can do anything you
want. For example, here is a script that converts two
characters to the left of current cursor position:
if it is "e" followed by apostrophe then it replaces it with é,

;---
#NoEnv
SendMode Input
SetWorkingDir %A_ScriptDir%

parse_clip(str) {
firstchar := substr(str, 1,1)
lastchar := substr(str, 2,2)
if  (lastchar = "'") {
if (firstchar = "e") {
Send, {raw}é
}
if (firstchar = "a") {
Send, {raw}á
}
}
else {
Send, {right}
}
}


Esc:: ExitApp

!c::
clipboard := ""
Send, {Shift down}{left}{left}{Shift up}
Send, ^c
Clipwait, 1
gettext := clipboard
parse_clip(gettext)
return

;---

So here the command is bound to Alt-C,
it selects two previus chars (shift+arrow commands), copies to clipboard
and parses the contents. It works system-wide, but
can be programmed to specific app as well.
Best thing is, you can program it youself as you like.
However if you want to program with AHK,
be prepared to invest time, it is not the easiest
programming language out there, only built-ins
probably more than hundred, so better not try to code without
syntax highlighting :)
.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Rustom Mody]

On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
> > You could go one step more sophisticated and use TeX-input method
> > (C-x RET C-\)
> > After which \'e will collapse as ÄC
> > â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may
ask
> > Trueâ | So as you rightly do,
> > - pick it up from google
> > - put emacs into tex input mode
> > - paste from google into emacs
> > - place point on the new char and type C-u C-x =
> >   Among other things emacs will helpfully inform you (among other things)
> >   to input: type "\'{e}" or "\'e" with TeX input method
>
> Which is closely related to the Compose key input method that I use.
> First, you assign a key on your keyboard to be Compose (at least on
> all my systems, there isn't one by default); I use the key between
> left Ctrl and left Alt.

Ha Ha So you wont speak the unspeakable?â¿!â¡

I also have my compose set (to Capslock) And I entered those chars above with
C?? and C!! where C is Capslock

I most frequently use that for âçÆ (C=>) âåÆ (C->) â1 (C^1) âéü (C_1) etc One
can find other goodies at /usr/share/X11/locale/en_US.UTF-8/Compose

I didn't start with mentioning that to Skip because his basic requirement (as I
 got it) was that
- input method should be OS-neutral
- emacs can be assumed

And so the only OS-non-neutrality that I am aware of is that sometimes Alt
works as Meta (gui-emacsen) and sometimes not terminal/text emacsen (typically,
 though I believe some ppl successfully tweak this also) And so M-x can mean
Alt-x (chord) or ESC-x (sequence) and a few such anomalies But beyond that
emacsen should be same for all OSes (modulo versions)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Alexandre Brault]

A quick Google search turned up WinCompose. It defaults to Right-Alt for
its compose key, but that's configurable


On 2017-11-27 02:05 PM, Paul Moore wrote:
> On 27 November 2017 at 18:13, Skip Montanaro  wrote:
>>> If you have a Windows key, you can assign it to be
>>> the Compose key.
>> Would this be true on a machine running Windows? My work environment
>> has me developing on Linux, with a Windows desktop. It's not clear to
>> me that any sort of xmodmap shennanigans would work. Won't Windows
>> itself always gobble up that key?
> Programs can access the Windows key. IIRC, there is a utility that
> provides compose-key functionality on Windows. I can't recall the name
> right now and it's on my other PC, not this one, but I'll try to
> remember to post the name tomorrow...
>
> Paul

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Rustom Mody]

On Friday, November 24, 2017 at 10:11:24 PM UTC+5:30, 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 strongly suspect that any recent emacs will have M-x insert-char (earlier it
was called ucs-insert) default bound C-x 8 RET (yeah thats clunky) which will
accept at the minibuffer input

At which point the hex for ÄC which is e9 can be entered â ö yeah its
unreasonable to expect to remember that! Its more reasonable to remember that
that is an e acute; And e itself is a latin lower case letter All of which
becomes entering (in the minibuffer) LATIN SMALL LETTER E ACUTE
- upper case not required; emacs will upcase it for you
- And will also provide some tab/star expansion help
ie *letter e acuteTAB
expands to
LATIN *L LETTER E ACUTE
Further TAB-prodding will give you these choices LATIN CAPITAL LETTER E ACUTE
(Äë)   LATIN CAPITAL LETTER E WITH ACUTE (Äë)
LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE (áº1)
LATIN CAPITAL LETTER E WITH MACRON AND ACUTE (á,û)
LATIN SMALL LETTER E ACUTE (ÄC) LATIN SMALL LETTER E WITH ACUTE (ÄC)
LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE (ế)
LATIN SMALL LETTER E WITH MACRON AND ACUTE (á,ù)

You could go one step more sophisticated and use TeX-input method (C-x RET C-\)
After which \'e will collapse as ÄC
â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may ask
Trueâ | So as you rightly do,
- pick it up from google
- put emacs into tex input mode
- paste from google into emacs
- place point on the new char and type C-u C-x =
  Among other things emacs will helpfully inform you (among other things)
  to input: type "\'{e}" or "\'e" with TeX input method

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Paul Moore]

On 27 November 2017 at 18:13, Skip Montanaro  wrote:
>> If you have a Windows key, you can assign it to be
>> the Compose key.
>
> Would this be true on a machine running Windows? My work environment
> has me developing on Linux, with a Windows desktop. It's not clear to
> me that any sort of xmodmap shennanigans would work. Won't Windows
> itself always gobble up that key?

Programs can access the Windows key. IIRC, there is a utility that provides
compose-key functionality on Windows. I can't recall the name right now and
it's on my other PC, not this one, but I'll try to remember to post the name
tomorrow...

Paul

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Chris Angelico]

On Tue, Nov 28, 2017 at 5:13 AM, Skip Montanaro
 wrote:
>> If you have a Windows key, you can assign it to be
>> the Compose key.
>
> Would this be true on a machine running Windows? My work environment
> has me developing on Linux, with a Windows desktop. It's not clear to
> me that any sort of xmodmap shennanigans would work. Won't Windows
> itself always gobble up that key?

Now that, I can't tell you about. As mentioned, the specific system I was using
 was provided by X11, so it wouldn't work on anything else. (Don't know about
Wayland; I think it might have an equivalent.) For other window managers, you'd
 have to find some alternative.

ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Skip Montanaro]

> I strongly suspect that any recent emacs will have M-x insert-char
> (earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats
clunky)
> which will accept at the minibuffer input

I tried C-x 8 e acute TAB

and was prompted with "E-acute". I don't know why it would have capitalized the
 "e". Still, I plowed ahead and hit RET

which yielded an "Invalid character" message in the minibuffer.

Skip

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Chris Angelico]

On Tue, Nov 28, 2017 at 1:55 AM, Rustom Mody  wrote:
> On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
>> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
>> > You could go one step more sophisticated and use TeX-input method
>> > (C-x RET C-\)
>> > After which \'e will collapse as ÄC
>> > â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may
ask
>> > Trueâ | So as you rightly do,
>> > - pick it up from google
>> > - put emacs into tex input mode
>> > - paste from google into emacs
>> > - place point on the new char and type C-u C-x =
>> >   Among other things emacs will helpfully inform you (among other things)
>> >   to input: type "\'{e}" or "\'e" with TeX input method
>>
>> Which is closely related to the Compose key input method that I use.
>> First, you assign a key on your keyboard to be Compose (at least on
>> all my systems, there isn't one by default); I use the key between
>> left Ctrl and left Alt.
>
> Ha Ha So you wont speak the unspeakable?â¿!â¡

Heh, you mean the term "Windows key"? It's not appropriate on keyboards that
don't have an actual Windows logo on it. There are other names for it, but I
figured the easiest way was to describe its location :D

But yes, that key. If you have a Windows key, you can assign it to be the
Compose key. Or, of course, you could redefine left control, so that Ctrl-X is
with the right key and Compose-X is with the left one. Or any other key you
like.

ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Skip Montanaro]

> If you have a Windows key, you can assign it to be
> the Compose key.

Would this be true on a machine running Windows? My work environment has me
developing on Linux, with a Windows desktop. It's not clear to me that any sort
 of xmodmap shennanigans would work. Won't Windows itself always gobble up that
 key?

Skip

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Chris Angelico]

On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody  wrote:
> You could go one step more sophisticated and use TeX-input method
> (C-x RET C-\)
> After which \'e will collapse as ÄC
> â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may
ask
> Trueâ | So as you rightly do,
> - pick it up from google
> - put emacs into tex input mode
> - paste from google into emacs
> - place point on the new char and type C-u C-x =
>   Among other things emacs will helpfully inform you (among other things)
>   to input: type "\'{e}" or "\'e" with TeX input method

Which is closely related to the Compose key input method that I use. First, you
 assign a key on your keyboard to be Compose (at least on all my systems, there
 isn't one by default); I use the key between left Ctrl and left Alt. Then you
have certain key sequences available that involve holding Compose and pressing
something, and then pressing something else. In the same way that you might
press Ctrl-X, Q to do something, you could press Compose-T, M to produce âäø.
Sounds complicated, but it's not. It's right enough. All your accented letters
can be created with Compose-accent, letter - eg Compose-apostrophe, e => ÄC, or
 Compose-backtick, a => Ä .

Not sure what systems that's supported on. I use Debian GNU/Linux with Xfce; I
believe the Compose key handling is all done by X11, so it should be fairly
widely available at least on Linux-derived systems.

ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Paul Moore]

On 27 November 2017 at 18:13, Skip Montanaro  wrote:
>> If you have a Windows key, you can assign it to be
>> the Compose key.
>
> Would this be true on a machine running Windows? My work environment
> has me developing on Linux, with a Windows desktop. It's not clear to
> me that any sort of xmodmap shennanigans would work. Won't Windows
> itself always gobble up that key?

Programs can access the Windows key. IIRC, there is a utility that
provides compose-key functionality on Windows. I can't recall the name
right now and it's on my other PC, not this one, but I'll try to
remember to post the name tomorrow...

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Skip Montanaro]

> If you have a Windows key, you can assign it to be
> the Compose key.

Would this be true on a machine running Windows? My work environment
has me developing on Linux, with a Windows desktop. It's not clear to
me that any sort of xmodmap shennanigans would work. Won't Windows
itself always gobble up that key?

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Tue, Nov 28, 2017 at 5:13 AM, Skip Montanaro
 wrote:
>> If you have a Windows key, you can assign it to be
>> the Compose key.
>
> Would this be true on a machine running Windows? My work environment
> has me developing on Linux, with a Windows desktop. It's not clear to
> me that any sort of xmodmap shennanigans would work. Won't Windows
> itself always gobble up that key?

Now that, I can't tell you about. As mentioned, the specific system I
was using was provided by X11, so it wouldn't work on anything else.
(Don't know about Wayland; I think it might have an equivalent.) For
other window managers, you'd have to find some alternative.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Tue, Nov 28, 2017 at 1:55 AM, Rustom Mody  wrote:
> On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
>> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
>> > You could go one step more sophisticated and use TeX-input method
>> > (C-x RET C-\)
>> > After which \'e will collapse as é
>> > “Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
>> > True… So as you rightly do,
>> > - pick it up from google
>> > - put emacs into tex input mode
>> > - paste from google into emacs
>> > - place point on the new char and type C-u C-x =
>> >   Among other things emacs will helpfully inform you (among other things)
>> >   to input: type "\'{e}" or "\'e" with TeX input method
>>
>> Which is closely related to the Compose key input method that I use.
>> First, you assign a key on your keyboard to be Compose (at least on
>> all my systems, there isn't one by default); I use the key between
>> left Ctrl and left Alt.
>
> Ha Ha So you wont speak the unspeakable?¿!¡

Heh, you mean the term "Windows key"? It's not appropriate on
keyboards that don't have an actual Windows logo on it. There are
other names for it, but I figured the easiest way was to describe its
location :D

But yes, that key. If you have a Windows key, you can assign it to be
the Compose key. Or, of course, you could redefine left control, so
that Ctrl-X is with the right key and Compose-X is with the left one.
Or any other key you like.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Skip Montanaro]

> I strongly suspect that any recent emacs will have M-x insert-char
> (earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats clunky)
> which will accept at the minibuffer input

I tried C-x 8 e acute TAB

and was prompted with "E-acute". I don't know why it would have
capitalized the "e". Still, I plowed ahead and hit RET

which yielded an "Invalid character" message in the minibuffer.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Rustom Mody]

On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
> > You could go one step more sophisticated and use TeX-input method
> > (C-x RET C-\)
> > After which \'e will collapse as é
> > “Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
> > True… So as you rightly do,
> > - pick it up from google
> > - put emacs into tex input mode
> > - paste from google into emacs
> > - place point on the new char and type C-u C-x =
> >   Among other things emacs will helpfully inform you (among other things)
> >   to input: type "\'{e}" or "\'e" with TeX input method
> 
> Which is closely related to the Compose key input method that I use.
> First, you assign a key on your keyboard to be Compose (at least on
> all my systems, there isn't one by default); I use the key between
> left Ctrl and left Alt. 

Ha Ha So you wont speak the unspeakable?¿!¡

I also have my compose set (to Capslock)
And I entered those chars above with C?? and C!! where C is Capslock

I most frequently use that for ⇒ (C=>) → (C->) ¹ (C^1) ₁ (C_1) etc
One can find other goodies at /usr/share/X11/locale/en_US.UTF-8/Compose

I didn't start with mentioning that to Skip because his basic requirement
(as I got it) was that
- input method should be OS-neutral
- emacs can be assumed

And so the only OS-non-neutrality that I am aware of is that sometimes
Alt works as Meta (gui-emacsen) and sometimes not terminal/text emacsen 
(typically, though I believe some ppl successfully tweak this also)
And so M-x can mean Alt-x (chord) or ESC-x (sequence) and a few such anomalies
But beyond that emacsen should be same for all OSes (modulo versions)
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody  wrote:
> You could go one step more sophisticated and use TeX-input method
> (C-x RET C-\)
> After which \'e will collapse as é
> “Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
> True… So as you rightly do,
> - pick it up from google
> - put emacs into tex input mode
> - paste from google into emacs
> - place point on the new char and type C-u C-x =
>   Among other things emacs will helpfully inform you (among other things)
>   to input: type "\'{e}" or "\'e" with TeX input method

Which is closely related to the Compose key input method that I use.
First, you assign a key on your keyboard to be Compose (at least on
all my systems, there isn't one by default); I use the key between
left Ctrl and left Alt. Then you have certain key sequences available
that involve holding Compose and pressing something, and then pressing
something else. In the same way that you might press Ctrl-X, Q to do
something, you could press Compose-T, M to produce ™. Sounds
complicated, but it's not. It's right enough. All your accented
letters can be created with Compose-accent, letter - eg
Compose-apostrophe, e => é, or Compose-backtick, a => à.

Not sure what systems that's supported on. I use Debian GNU/Linux with
Xfce; I believe the Compose key handling is all done by X11, so it
should be fairly widely available at least on Linux-derived systems.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Rustom Mody]

On Friday, November 24, 2017 at 10:11:24 PM UTC+5:30, 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 strongly suspect that any recent emacs will have M-x insert-char
(earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats clunky)
which will accept at the minibuffer input

At which point the hex for é which is e9 can be entered — yeah its unreasonable 
to expect to remember that!
Its more reasonable to remember that that is an e acute; 
And e itself is a latin lower case letter
All of which becomes entering (in the minibuffer)
LATIN SMALL LETTER E ACUTE
- upper case not required; emacs will upcase it for you
- And will also provide some tab/star expansion help
ie *letter e acuteTAB 
expands to
LATIN *L LETTER E ACUTE
Further TAB-prodding will give you these choices
LATIN CAPITAL LETTER E ACUTE (É)LATIN CAPITAL LETTER E WITH ACUTE (É)
LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE (Ế)
LATIN CAPITAL LETTER E WITH MACRON AND ACUTE (Ḗ)
LATIN SMALL LETTER E ACUTE (é)  LATIN SMALL LETTER E WITH ACUTE (é)
LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE (ế)
LATIN SMALL LETTER E WITH MACRON AND ACUTE (ḗ)

You could go one step more sophisticated and use TeX-input method
(C-x RET C-\)
After which \'e will collapse as é
“Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
True… So as you rightly do, 
- pick it up from google
- put emacs into tex input mode
- paste from google into emacs
- place point on the new char and type C-u C-x =
  Among other things emacs will helpfully inform you (among other things)
  to input: type "\'{e}" or "\'e" with TeX input method
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Rustom Mody]

On Friday, November 24, 2017 at 10:52:47 PM UTC+5:30, Rick Johnson wrote:
> Furthermore, if we are to march headlong onto the glorious
> battlefields of diversity and equality…

Obligatory viewing for those who underappreciate diversity, equality and such

https://youtu.be/Zh3Yz3PiXZw

[My old colleague, a numerical analyst pointed out to me today that the 
'correct 
answer' is not twenty two thousand but twenty million two thousand]
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Andrew Z]

Thank you Rick for well thought out argument.



On Nov 24, 2017 12:44, "Rick Johnson"  wrote:

> On Thursday, November 23, 2017 at 9:57:12 PM UTC-6, Ben Finney wrote:
> [...]
> > This is a necessary consequence of increasing the diversity
> > of people able to program in Python: people will express
> > ideas originating in their own language, in Python code.
> > For that diversity to increase, we English-fluent folk will
> > necessarily become a smaller proportion of the programming
> > community than we are today. That might be uncomfortable
> > for us, but it is a necessary adaptation the community
> > needs to undergo.
>
> Will your heroic crusade to bring equality to the shire also
> include Python standard library modules written in languages
> other than English? If so, then you'll need to contact
> Guido, as PEP8 will require some editing.
>
> Speaking of GvR...
>
> And even if you did managed to bring multilingualism to
> Python scripts and std-lib modules, wouldn't such
> "diversity" be merely symbolic?
>
> Hmm, because, when we consider the make-up of pydev (aka:
> nothing but English speaking dudes) we realize that there
> really isn't any diversity at all. At least, not where it
> matters. (aka: where the decision are being made)
>
> Furthermore, if we are to march headlong onto the glorious
> battlefields of diversity and equality, for the sake of all
> else, then, why should Guido's position be off limits? I
> mean, sure, he may a brilliant man. But he's surely not the
> most brilliant man on this planet, is he?
>
> And with that liberating thought in mind, may i offer an
> excerpt, for your intellectual consumption, from one of the
> most famous documents of all time?
>
> (emphasis mine)
>
> "Prudence, indeed, will dictate that governments long
> established should not be changed for light and transient
> causes; and accordingly, all experience hath shewn, that
> [humankind] are more disposed to _suffer_ while evils are
> _sufferable_, than to right themselves by abolishing the
> forms to which they are "accustomed"; but when a ~long~
> train of abuses and usurpations, pursuing invariably the
> same object, evinces a _design_ to reduce them under
> absolute *DESPOTISM* -- It is their *RIGHT*! It is their
> *DUTY*! -- to throw off such government and to provide new
> guards for their future security"
>
> ...Declaration of Independence: July 4, 1776
>
> I'm of the opinion that diversity is fine, so long as you
> don't make the fatal mistake of "lopping off your nose to
> spite your face".
>
> Take, for example, the accommodations our societies offer
> for handicapped people -- from wheel chair ramps, to
> reserved front-row parking spaces, to widened doorways,
> etc... -- these accommodations do *NOT*, in any way,
> undermine the accessability of healthy people who also utilize
> these same public spaces. In fact, the worst consequence of
> these accommodations might be that you and i must walk a few
> more steps from our car to the market.
>
> Big deal!
>
> But what you are suggesting is not so much an
> _accommodation_, as it is a fundamental fissure in our
> ability to communicate, one that will fracture the community
> far more than it is today. It would be as foolish as
> mandating that everyone must have their legs lopped-off, so
> that all will be "equal".
>
> Yes, diversity is great! But only when it welcomes outsiders
> without undermining the practical cohesiveness of the wider
> community. And if the result of your little "inclusivity
> project" is merely the replacement of N domestic community
> members with N foreign community members, foreigners who's
> regional dialects will muck-up the communication process,
> then it seems to me that what you have gained is merely a
> fulfillment of your _own_ emotional needs, at the expense of
> all.
>
> In conclusion.
>
> While a wise student of knowledge recognizes that:
>
> (1) social groups who have waxed into a homogenous block
> actually undermine themselves, because they lack the
> essential diversity of ideas required to see beyond the
> walls of their own "box", and the confirmation bias that
> infests such societies, will ensure that such a community is
> an evolutionary dead end.
>
> The same student _also_ recognizes that:
>
> (2) a society which resembles a jig-saw-puzzle dumped
> haphazardly on the floor, lacks the essential _cohesiveness_
> required to maintain a strong sense of _community_, a sense
> which allows multiple individuals to work towards a common
> goal, in manner this is both practical and efficient.
>
> Something to think about.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Richard Damon]

On 11/24/17 12:35 PM, Skip Montanaro wrote:

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.

I think you misunderstood my post. For that I apologize that I wasn't clear.

I was only pointing out that there is a ton of inertia based on the
long dominance of ASCII (and before that EBCDIC) and its downstream
effects on computer entry systems. I know that there are likely
semi-reasonable ways to enter accented characters on my keyboard, but
they are unknown to me, and will likely be different on the different
systems I use, so I've not bothered to learn any of them.

One thing which occurred to me as I was typing my earlier message, but
which I failed to include... I wonder if when you go to Dell (for
example) to configure a computer, you can easily specify a non-ASCII
keyboard for a machine destined for delivery to the US. Maybe it's
trivial, but maybe it's just enough more difficult (slows delivery,
costs a few bucks more, which of the alternatives should you choose?)
that people think, "Ah hell, might as well just go with the ASCII
keyboard."

I'm clearly in the old fart camp at this point. Perhaps American
software engineers half my age aren't afflicted by my career-long
biases.

Skip

I doubt I am 1/2 your age (are you 120 yet?). The keyboard I normally 
use would be very hard to use for foreign characters, but I do 
understand that if I wanted to, I could easily get a keyboard designed 
for use in any other language. Some would take some training to learn 
how to use (like a Chinese keyboard).


The fact that I was pointing out is that the fact that people are 
arguing that because *THEY* would have difficulty working with a code 
base (that they likely would never actually need access to) is a good 
reason from preventing others, who already HAVE the needed 
hardware/training from being able to make the code more readable to them.


As far as the basic ability to enter arbitrary characters,  most OSes 
have a generic entry method (like windows ALT-numbers method) and I 
think most have a character selector app to add arbitrary characters to 
the clipboard. Yes, this may not be very convenient for a lot of use but 
is possible. Also, it is generally possible to select an alternate 
keyboard map for your keyboard to enter other characters, you then just 
need to know (or have printed) the new mapping of the keyboard. It helps 
if you do this to have learned the new mapping, and how to touch type on 
that keyboard. Generally you can also get Keyboard Stickers to place on 
your keyboard if you are a hunt and pecker typist.


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

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

[Skip Montanaro]

> 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.

I think you misunderstood my post. For that I apologize that I wasn't clear.

I was only pointing out that there is a ton of inertia based on the
long dominance of ASCII (and before that EBCDIC) and its downstream
effects on computer entry systems. I know that there are likely
semi-reasonable ways to enter accented characters on my keyboard, but
they are unknown to me, and will likely be different on the different
systems I use, so I've not bothered to learn any of them.

One thing which occurred to me as I was typing my earlier message, but
which I failed to include... I wonder if when you go to Dell (for
example) to configure a computer, you can easily specify a non-ASCII
keyboard for a machine destined for delivery to the US. Maybe it's
trivial, but maybe it's just enough more difficult (slows delivery,
costs a few bucks more, which of the alternatives should you choose?)
that people think, "Ah hell, might as well just go with the ASCII
keyboard."

I'm clearly in the old fart camp at this point. Perhaps American
software engineers half my age aren't afflicted by my career-long
biases.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Rick Johnson]

On Thursday, November 23, 2017 at 9:57:12 PM UTC-6, Ben Finney wrote:
[...]
> This is a necessary consequence of increasing the diversity
> of people able to program in Python: people will express
> ideas originating in their own language, in Python code.
> For that diversity to increase, we English-fluent folk will
> necessarily become a smaller proportion of the programming
> community than we are today. That might be uncomfortable
> for us, but it is a necessary adaptation the community
> needs to undergo.

Will your heroic crusade to bring equality to the shire also
include Python standard library modules written in languages
other than English? If so, then you'll need to contact
Guido, as PEP8 will require some editing.

Speaking of GvR... 

And even if you did managed to bring multilingualism to
Python scripts and std-lib modules, wouldn't such
"diversity" be merely symbolic?

Hmm, because, when we consider the make-up of pydev (aka:
nothing but English speaking dudes) we realize that there
really isn't any diversity at all. At least, not where it
matters. (aka: where the decision are being made)

Furthermore, if we are to march headlong onto the glorious
battlefields of diversity and equality, for the sake of all
else, then, why should Guido's position be off limits? I
mean, sure, he may a brilliant man. But he's surely not the
most brilliant man on this planet, is he?

And with that liberating thought in mind, may i offer an
excerpt, for your intellectual consumption, from one of the
most famous documents of all time?

(emphasis mine)

"Prudence, indeed, will dictate that governments long
established should not be changed for light and transient
causes; and accordingly, all experience hath shewn, that
[humankind] are more disposed to _suffer_ while evils are
_sufferable_, than to right themselves by abolishing the
forms to which they are "accustomed"; but when a ~long~
train of abuses and usurpations, pursuing invariably the
same object, evinces a _design_ to reduce them under
absolute *DESPOTISM* -- It is their *RIGHT*! It is their
*DUTY*! -- to throw off such government and to provide new
guards for their future security"

...Declaration of Independence: July 4, 1776

I'm of the opinion that diversity is fine, so long as you
don't make the fatal mistake of "lopping off your nose to
spite your face".

Take, for example, the accommodations our societies offer
for handicapped people -- from wheel chair ramps, to
reserved front-row parking spaces, to widened doorways,
etc... -- these accommodations do *NOT*, in any way,
undermine the accessability of healthy people who also utilize
these same public spaces. In fact, the worst consequence of
these accommodations might be that you and i must walk a few
more steps from our car to the market.

Big deal!

But what you are suggesting is not so much an
_accommodation_, as it is a fundamental fissure in our
ability to communicate, one that will fracture the community
far more than it is today. It would be as foolish as
mandating that everyone must have their legs lopped-off, so
that all will be "equal".

Yes, diversity is great! But only when it welcomes outsiders
without undermining the practical cohesiveness of the wider
community. And if the result of your little "inclusivity
project" is merely the replacement of N domestic community
members with N foreign community members, foreigners who's
regional dialects will muck-up the communication process,
then it seems to me that what you have gained is merely a
fulfillment of your _own_ emotional needs, at the expense of
all.

In conclusion. 

While a wise student of knowledge recognizes that:

(1) social groups who have waxed into a homogenous block
actually undermine themselves, because they lack the
essential diversity of ideas required to see beyond the
walls of their own "box", and the confirmation bias that
infests such societies, will ensure that such a community is
an evolutionary dead end.

The same student _also_ recognizes that:

(2) a society which resembles a jig-saw-puzzle dumped
haphazardly on the floor, lacks the essential _cohesiveness_
required to maintain a strong sense of _community_, a sense
which allows multiple individuals to work towards a common
goal, in manner this is both practical and efficient.

Something to think about.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 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

--
https://mail.python.org/mailman/listinfo/python-list

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

[Skip Montanaro]

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas Jollans]

On 24/11/17 05:45, Andrew Z wrote:
> I have hard time seeing the benefits of this "necessity" , just
> unreasonable  overcomplications for the name of "diversity".

What complications?
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Andrew Z]

I have hard time seeing the benefits of this "necessity" , just
unreasonable  overcomplications for the name of "diversity".




On Nov 23, 2017 22:57, "Ben Finney"  wrote:

> Ian Kelly  writes:
>
> > On Thu, Nov 23, 2017 at 1:04 PM, Karsten Hilbert
> >  wrote:
> > > Using function arguments written in Thai script ?
> > >
> > > Understanding, let alone being able to read, code written in Arabic
> > > ?
> >
> > People are going to write code in Arabic whether you like it or not,
> > because not everybody speaks English, and not everybody who does
> > *wants* to use it.
>
> This is, I think, a good reason to allow Unicode identifiers (at least,
> those Unicode subsets which encode writing systems of languages) as
> programming-language identifiers.
>
> > Now, would you prefer to read code where the variable names are
> > written in Arabic script, or where the variable names are still in
> > Arabic but transliterated to Latin characters?
>
> (On the – evidently correct, in Karsten's case and mine – assumption
> that the reader does not understand Arabic script.)
>
> I've thought about this, and if the quesition is which would *I* prefer,
> the answer is I'd prefer the identifiers transliterated to the Latin
> (English-writing) characters.
>
> 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.
>
> Set against that, though, I want the preferences of *others* to be taken
> into consideration also. And there are many more people who do not
> natively write English/Latin characters, that I want to feel welcome in
> the Python community.
>
> So it's a good thing that my own reading preference *does not* have
> weight in this matter. I'm not the primary audience for code identifiers
> written in Arabic script, so my preference should matter less than those
> who understand it.
>
> > Either way, you're not going to be able to understand it, so I'm not
> > sure why it makes a difference to you.
>
> I hope you can see that it can simultaneously make a difference – I
> would definitely prefer to read Latin-writing identifiers – while also
> being a lesser consideration that should not outweigh the benefits of
> allowing non-Latin-script identifiers.
>
> > If Arabic characters are allowed however, then it might be of use to
> > the people who are going to code in Arabic anyway. And if it isn't,
> > then they have the option not to use it either.
>
> This is a necessary consequence of increasing the diversity of people
> able to program in Python: people will express ideas originating in
> their own language, in Python code.
>
> For that diversity to increase, we English-fluent folk will necessarily
> become a smaller proportion of the programming community than we are
> today. That might be uncomfortable for us, but it is a necessary
> adaptation the community needs to undergo.
>
> --
>  \ “In any great organization it is far, far safer to be wrong |
>   `\  with the majority than to be right alone.” —John Kenneth |
> _o__)Galbraith, 1989-07-28 |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list