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

[Rustom Mody]

On Tuesday, March 25, 2014 12:28:16 AM UTC+5:30, Mark H. Harris wrote:
> On 3/24/14 4:58 AM, Mark Lawrence wrote:
> > Where do you get reduce from if it's not in the standard library?

>     That was "a" proposal for 3000. Its there, but its not on the 
> built-ins; ie., you have to import it.  The confusion: why reduce, why 
> not filter, nor map?  {rhetorical}

> > As for lambda I've no real interest in it, other than when copying examples
> > where it's used to (say) provide a key function.

> This is one of my main points to Steven. In my experience "most" people 
> do not intend to use lambda for anything; they are trying to sort this 
> or that and don't quite know how to get the key right and some helpful 
> somebody gives them a key=lambda yadda yadda .  They use it, and it 
> works, but they are scratching their head saying to themselves, "what it 
> that, how does it work, how can I understand it and on and on".

Your example backfires more than you perhaps realize
1. Most people who-have-not-heard-of (WHNHO) generators dont intend to use
generators. Somebody shows then a couple of uses and they then find them
useful in other contexts
2. Most programmers coming from C where vararg exists but is really
much too painful to use outside of printf, dont want to use default
arguments. Somebody shows them default arguments then they find nifty uses
for the same
3. Most people WHNHO special methods ...
4. Most people WHNHO slices ...

Just sayin...

> That is what we mean by confusing. Or another really great example is 
> this thread. Somebody asks about a language feature and somebody else 
> helpfully answers the question by providing them with a similar lambda!!

I am not in pro or anti lambda camp.
My grouses are 3, all re comprehensions

1. Technical: I consider the comprehension binding rules wrong -- not lambda
2. Methodological: Experienced people showing comprehensions
as 'nothing more than' a short-form for a for-loop are being less helpful
to the noob than they know.
3. Pedagogical: Comprehensions are hard, for loops are easy.

To convey comprehensions two contrasting perspectives are needed:
1. The for-loop view
2. The set-theory view

Give only one, and misunderstandings and confusions proliferate
Yes 'only one' can be either one. In the haskell world the pedagogical error
tends to be the opposite to the one out here:
Noobs write: [... x in l, y in m,...]
and wonder why the efficiency is vastly different from
[... y in m, x in l, ...]

Comes from emphasising the declarative (set-theory) view too much, the
imperative (for-loop) view too little