Hi all, thank you for the feedback. I laughed, I cried, and I learned.
I looked over all your suggestions and recreated them here:
https://github.com/petered/peters_example_code/blob/master/peters_example_code/ways_to_skin_a_cat.py
I still favour my (y = f(y, x) for x in xs from y=initializer) syntax for a
few reasons:
1) By adding an "initialized generator" as a special language construct,
we could add a "last" builtin (similar to "next") so that
"last(initialized_generator)" returns the initializer if the
initialized_generator yields no values (and thus replaces reduce).
2) Declaring the initial value as part of the generator lets us pass around
the generator around so it can be run in other scopes without it keeping
alive the scope it's defined in, and bringing up awkward questions like
"What if the initializer variable in the scope that created the generator
changes after the generator is defined but before it is used?"
3) The idea that an assignment operation "a = f()" returns a value (a) is
already consistent with the "chained assignment" syntax of "b=a=f()" (which
can be thought of as "b=(a=f())"). I don't know why we feel the need for
new constructs like "(a:=f())" or "(f() as a)" when we could just think of
assignments as returning values (unless that breaks something that I'm not
aware of)
However, it looks like I'd be fighting a raging current if I were to try
and push this proposal. It's also encouraging that most of the work would
be done anyway if ("Statement Local Name Bindings") thread passes. So some
more humble proposals would be:
1) An initializer to itertools.accumulate
functools.reduce already has an initializer, I can't see any controversy to
adding an initializer to itertools.accumulate
2) Assignment returns a value (basically what's already in the "Statement
local name bindings" discussion)
`a=f()` returns a value of a
This would allow updating variables in a generator (I don't see the need
for ":=" or "f() as a") but that's another discussion
Is there any interest (or disagreement) to these more humble proposals?
- Peter
On Fri, Apr 6, 2018 at 2:19 AM, Serhiy Storchaka <storch...@gmail.com>
wrote:
> 05.04.18 19:52, Peter O'Connor пише:
>
>> I propose a new "Reduce-Map" comprehension that allows us to write:
>>
>> signal = [math.sin(i*0.01) + random.normalvariate(0, 0.1)for iin
>> range(1000)]
>> smooth_signal = [average = (1-decay)*average + decay*xfor xin signalfrom
>> average=0.]
>>
>
> Using currently supported syntax:
>
> smooth_signal = [average for average in [0] for x in signal
> for average in [(1-decay)*average + decay*x]]
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
