2016-11-06 23:55 GMT-02:00 Steven D'Aprano <steve@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@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@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@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)