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