[Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

[Danilo J. S. Bellini]

2016-11-06 23:55 GMT-02:00 Steven D'Aprano <steve at pearwood.info>:

> On Sun, Nov 06, 2016 at 04:46:42PM -0200, Danilo J. S. Bellini wrote:
>
> > 1.2. Sub-expressions in an expression might be on other statements (e.g.
> > assignments, other functions).
>
> Not in Python it can't be. Assignment is not an expression, you cannot
> say (x = 2) + 1.
>

O.o ... how is that (x = 2) + 1 related to what I wrote?
Say you have "d = a + b + c", you can write it as "h = a + b" then "d = h +
c"...
The expression "a + b + c" and the new "h + c" are equivalent because the
sub-expression "a + b" was assigned to "h" elsewhere (another statement).


2016-11-06 23:55 GMT-02:00 Steven D'Aprano <steve at pearwood.info>:

> > 2. The itertools.accumulate function signature is broken:
> > 2.1. Its arguments are reversed when compared to other higher order
> > functions like map, filter and reduce.
>
> That's only "broken" if you think that we should be able to swap
> accumulate for map, filter and reduce. But that's not the case:
> accumulate is NOT broken because the API is not intended to be the same
> as map, filter and reduce. The API for accumulate is that the iterable
> is mandatory, but the function argument is *not*.
>

I'd say not even on map and filter requires a function, as "None" means
"lambda x: x" on them, strangely enough.

All of them are higher order functions in the standard Python, and you can
include other functions like itertools.takewhile and itertools.dropwhile to
this comparison. The accumulate signature is simply
broken/different/surprising in that context.


2016-11-06 23:55 GMT-02:00 Steven D'Aprano <steve at pearwood.info>:

> > 3. It's not about "adding complexity", it's the other way around:
>
> No, I'm sorry, it does add complexity.
>

Compared to the alternatives, it's the other way around: my proposal
removes complexity from the resulting code that requires a scan.

Unless you're saying so because it's a proposal to change CPython, and as
CPython itself would get a new feature, it would "be more complex"... I
agree: any change would either add complexity somewhere or be backwards
incompatible. Which one is better? Why this mail list exists?


2016-11-06 23:55 GMT-02:00 Steven D'Aprano <steve at pearwood.info>:

> List comprehensions are not intended for these sorts of complex
> calculations.
>

I know list comprehensions aren't yet intended for scan, otherwise why
would I propose this? Triple-for-sections list comprehensions are
complicated, and it's actually surprising that Python allows using the same
target variable name twice on them.

But the calculation itself and its declarative description aren't complex.
Even you wrote such a declarative description in your e-mail, when
explaining what "series" are.

-- 
Danilo J. S. Bellini
---------------
"*It is not our business to set up prohibitions, but to arrive at
conventions.*" (R. Carnap)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161107/2dbe744e/attachment.html>