Unicode in Python

[Rustom Mody]

On Wednesday, April 23, 2014 11:22:33 AM UTC+5:30, Steven D'Aprano wrote:

> 25 Unicode characters down, 1114000+ to go :-)

The question would arise if there was some suggestion to add
1114000(+) characters to the syntactic/lexical definition of python.

IOW while its true that unicode is a character-set, its better to think
of it as a repertory  -- here is the universal set from which a choice is available.

On Wednesday, April 23, 2014 11:20:35 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Apr 23, 2014 at 3:31 PM, Rustom Mody wrote:
> > Chris Angelico wrote:
> >> it's impossible for most people to type (and programming with a palette
> >> of arbitrary syntactic tokens isn't my idea of fun)...
> > Where's the suggestion to use a "palette of arbitrary tokens" ?
> > I just tried a greek keyboard; ie do
> > $ setxkbmap -option "grp:switch,grp:alt_shift_toggle,grp_led:scroll" -layout "us,gr"
> > Thereafter typing
> > abcdefghijklmnopqrstuvwxyz
> > after a Shift-Alt
> > gives
> > αβψδεφγηιξκλμνοπ;ρστθωςχυζ
> > One more Shift-Alt and back to roman

> Okay. Now what about your other symbols? Your alternative assignment
> operator, for instance. How do you type that?

In case you missed it, I said:

> Of course
> - One would need to define such a keyboard (setxkb)
> - One would have to find similar technologies for other OSes

In more detail:
In our normal use of a US-104 keyboard, every letter 'costs' something.
eg 'a' costs 1 keystroke
   'A' costs 2 (Shift+a)
Most people do not count that as a significant cost.
and when kids come on this list and talk smsese -- i wanna do so-n-so

we chide them for keystrokes at the cost of readability.

In such a (default) setup typing a ∧ or ∨ is not possible at all without
something like a char-picker and at best has an ergonomic cost that is an
order of magnitude higher than the 'naturally available' characters.

On the other hand when/if a keyboard mapping is defined in which
the characters that are commonly needed are available, it is
reasonable to expect the ∨,∧ to cost no more than 2 strokes each
(ie about as much as an 'A'; slightly more than an 'a'. Which means
that '∨' is expected to cost about the same as 'or' and ∧ to cost less than an 'and'

Readability is another question altogether.
Random example from my machine
calendar.py line 99
If one finds this:

return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)

more readable than
return year%4=0 ∧ (year%100≠0  ∨  year%100 = 0)
then perhaps the following is the most preferred?

COMPUTE YEAR MODULO 4 EQUALS 0 AND YEAR MODULO 100 NOT
EQUAL TO ZERO OR YEAR MODULO 100 EQUAL to 0

IOW COBOL is desirable?