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

[Danilo J. S. Bellini]

>
> As a practicing economist, I wonder what use cases you're referring
> to.  I can't think of any use cases where if one previous value is
> useful, having all previous values available (ie, an arbitrary
> temporal structure, at the modeler's option) isn't vastly more useful.
>

Well, see the itertools.accumulate examples yourself then, the ones at
docs.python.org... We can start with something really simple like interest
rates or uniform series, but... before arguing here, please convince other
people to update the Wikipedia:

"Recurrence relations, especially linear recurrence relations, are used
extensively in both theoretical and empirical economics."
https://en.wikipedia.org/wiki/Recurrence_relation#Economics

So in the end, even if there are plausible use cases for quick and dirty
> code, [...]
>

The proposal isn't about quick and dirty code. The State-space example
includes a general linear time-varying MIMO simulation implementation
trying to keep the syntax as similar as possible to the control theory
engineers are used to. Also, my goal when I was looking for a scan syntax
to solve the conditional toggling example was to make it cleaner.

If you aren't seeing the examples I wrote, I wonder what are you writing
about.

There was a discussion about this a while ago.


And where's the link?

[...]. From what
> I remember, the conclusion reached was that there are too
> many degrees of freedom to be able to express reduction
> operations in a comprehension-like way that's any clearer
>

I don't know if that's a conclusion from any other thread, but that's
wrong. The only extra "freedom" required a way to access the previous
output (or "accumulator", "memory", "state"... you can use the name you
prefer, but they're all the same). How many parameters does itertools.scan
have? And map/filter?

I can't talk about a discussion I didn't read, it would be unfair,
disrespectful. Perhaps that discussion was about an specific proposal and
not about the requirements to express a scan/fold.

This proposal should be renamed to "recursive list comprehension". 3 words,
and it's a complete description of what I'm talking about. For people from
a functional programming background, that's about an alternative syntax to
write the scan higher order function.

Forget the word "reduce", some people here seem to have way too much taboo
with that word, and I know there are people who would prefer a higher
McCabe complexity just to avoid it. Perhaps there are people who prefer
masochist rituals instead of using "reduce", who knows? Who cares? I like
reduce, but I'm just proposing a cleaner syntax for recursive list
comprehensions, and "reduce" isn't the general use case for that. On the
contrary, "reduce" is just the specific scenario where only the last value
matters.

[...] you better  have a VERY GOOD reason.


I spent months writing PyScanPrev, mainly the examples in several
reStructuredText files, not because I was forcing that, but because there
are way too many use cases for it, and I know those examples aren't
exhaustive.

https://pypi.python.org/pypi/pyscanprev

But talking about "good reasons" reminds me of the "annotations"! A
function that uses annotations for one library can't use annotations for
another library unless their annotation values are the same, but if one
package/framework needs "type information" from your function
parameters/result and another package/framework collects "documentation"
from it, there's no way to get that working together. Something like "x :
int = 2" makes the default assignment seem like an assignment to the
annotation, and there's even a new token "->" for annotations. When I saw
Python annotations at first I though it was a joke, now I know it's
something serious with [mutually incompatible] libraries/packages using
them. I strongly agree that everything should need a good reason, but I
wrote a lot about the scan use cases and no one here seem to have read what
I wrote, and the only reason that matters seem to be a kind of social
status, not really "reason". I probably wrote way more reasons for that
proposal than annotations could ever have. But if no one seem to care
enough to read, then why should I insist? That's like my pprint bugfix
patch some months ago, was it applied? AFAIK not even core developers
giving +1 was enough for it to be applied.

This maillist isn't very inviting... but I hope some of you at least try to
read the rationale and the examples.

-- 
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/20161025/ddadab6c/attachment-0001.html>