[Python-Dev] accumulator display syntax

[Brett C.]

Skip Montanaro wrote:

>     >> But, indexing does stretch quite far in the current Python syntax and
>     >> semantics (in Python's *pragmatics* you're supposed to use it far
>     >> more restrainedly).
> 
>     Guido> Which is why I didn't like the 'sum[x for x in S]' notation much.
>     Guido> Let's look for an in-line generator notation instead.  I like
> 
>     Guido>   sum((yield x for x in S))
> 
>     Guido> but perhaps we can make this work:
> 
>     Guido>   sum(x for x in S)
> 
> Forgive my extreme density on this matter, but I don't understand what
> 
>     (yield x for x in S)
> 
> is supposed to do.  

In an attempt to make sure I understand what is being discussed, I am 
going to take a stab at this.  That way when someone corrects me two 
people get there questions; two birds, one shotgun.

> Is it supposed to return a generator function which I
> can assign to a variable (or pass to the builtin function sum() as in your
> example) and call later, or is it supposed to turn the current function into
> a generator function (so that each executed yield statement returns a value
> to the caller of the current function)?
> 

It returns a generator function.

> Assuming the result is a generator function (a first class object I can
> assign to a variable then call later), is there some reason the current
> function notation is inadequate?  This seems to me to suffer the same
> expressive shortcomings as lambda.  Lambda seems to be hanging on by the
> hair on its chinny chin chin.  Why is this construct gaining traction?  If
> you don't like lambda, I can't quite see why syntax this is all that
> appealing.
>

Extreme shorthand for a common idiom?

> OTOH, if lambda: x: x+1 is okay, then why not:
> 
>     yield: x for x in S
> 

I was actually thinking that myself, but I would rather keep lambda as 
this weird little child of Python who can always be spotted for its 
predisposition toward pink hot pants (images of "Miami Vice" flash in my 
head...).

Personally I am not seeing any extreme need for this feature.  I mean 
the example I keep seeing is ``sum((yield x*2 for x in foo))``.  But how 
is this such a huge win over ``sum([x*2 for x in foo])``?  I know there 
is a memory perk since the entire list won't be constructed, but unless 
there is a better reason I see abuse on the horizon.

The misuse of __slots__ has shown that when something is added that 
seems simple and powerful it will be abused by a lot of programmers 
thinking it is the best thing to use for anything they can shoe horn it 
into.  I don't see this as such an abuse issue as __slots__, mind you, 
but I can still see people using it where a list comp may have been 
better.  Or even having people checking themselves on whether to use 
this or a list comp and just using this because it seems cooler.

I know I am personally +0 on this even after my above worries since I 
don't see my above arguments are back-breakers and those of us who do 
know how to properly to use it will get a perk out of it.

-Brett