Time we switched to unicode? (was Explanation of this Python language feature?)

[Rustom Mody]

On Tuesday, March 25, 2014 8:47:35 AM UTC+5:30, Chris Angelico wrote:
> On Tue, Mar 25, 2014 at 2:00 PM, Rustom Mody wrote:
> > Yeah: Its 2014 (at least out here)...
> > About time we started using unicode in earnest dont you think??

> We do.

> > Id like to see the following spellings corrected:
> > lambda to λ
> > in to ∈
> > (preferably with the 'in' predicate and the 'in' in 'for' disambiguated)
> > set([]) to ∅

> The problems with these is not Unicode or a lack thereof, but keys. I
> know how to type "lambda" on any keyboard I reach for; if it's a
> full-sized QWERTY variant, I can type it without looking, and if it's
> something else then I can peer at the thing and find the appropriate
> five letters. (Phone keyboards are notoriously peer-worthy.) How do I
> type λ? Do I have to memorize an alt-key sequence? Do I need to keep a
> set of "language keywords" in a file somewhere so I can copy and
> paste? Does my editor have to provide them?

> What is really gained by using the short-hand? It becomes nigh
> ungoogleable; yes, you can paste λ into Google and find out that it's
> called lambda (and, if Python used that as a keyword, you could type
> "λ python" into Google and get to the docs), but how do you figure out
> which part of this to search for?

> sockets.sort(key=λdata:data[1])

> More likely you'd search for "sockets" or "sort" or maybe "key" or
> "data", but you wouldn't expect to search for the symbol.

> > And some parentheses disambiguation
> > Internal ambiguity: Is '(...)' a paren? a function? a tuple?
> > External ambiguity: {} in python vs in set theory

> I don't know about the difference between {} in set theory and Python,
> but the multiple uses of () actually boil down to two:

> 1) Grouping, which includes tuples; there's a special case whereby
> grouping nothing makes a zero-item tuple, but everything else is just
> the comma

> 2) Functions (both definition and call)

> Disambiguating them might be of some small value, but since they're
> the same in pretty much every language under the sun, it would feel
> like syntactic salt: you have to use a different, and hard to type,
> form of parenthesis for one (or even both!) of what ought to just be
> simple brackets.

> And what's the benefit? Shorter code, maybe. A few 2-6 letter
> sequences that can become single characters. I can sympathize somewhat
> with the set issue (because {} means an empty dict), although set() is
> better than set([]); having a short form for that would be of some
> advantage. But not if it's hard to type.

> ChrisA

Of all your objections, the 'google-able' one is the most hard-hitting.
Yes its important and I have no answers.

What you are missing is that programmers spend
90% of their time reading code
10% writing code

You may well be in the super-whiz category (not being sarcastic here)
All that will change is upto 70-30. (ecause you rarely make a mistake)
You still have to read oodles of others' code

I find python (as haskell) sweet because they dont force me read
parsing-drudgery like '{}'.
Given that a compiler can parse whitespace (python), or '{}' (C) in microseconds
whereas I take seconds, this is really terrible economics

Increasing the lexical variety of the code is in the same direction
[There is no need implied that overdoing it and becoming APL is good :-) ]