Re: Increasing the diversity of people who write Python
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
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
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
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)
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
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)
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)
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
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:
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
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:
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:
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:
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:
> 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:
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:
> 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:
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)
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)
> 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)
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)
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)
> 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)
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)
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)
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)
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)
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
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)
> 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)
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)
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)
> 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)
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)
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