On Tue, Dec 28, 2021 at 12:49:13AM +0900, Stephen J. Turnbull wrote:
> The point is that you focus on the lambdas, but what I'm interested in
> is the dataflows (the implicitly constructed iterators). In fact you
> also created a whole new subordinate data flow that doesn't exist in
> the original (the [x+1]). I haven't checked but I bet that a complex
> comprehension in your style will need to create a singleton iterable
> per source element for every mapping except the first.
I believe that Serhiy has optimized the case where a comprehension loops
over a singleton list or tuple. If you go back to the pre-walrus
operator discussion (PEP 572) one of the alternatives was to use a
second loop.
[func(y) for x in items for y in [x+1] if condition(y)]
# inner loop ...........^^^^^^^^^^^^^^
The second loop was not mentioned in the PEP, but it was discussed
during the mega-threads (note plural). If my recollection serves me
correctly, at some point Serhiy optimized the inner loop away.
If you inspect the output of:
import dis
dis.dis("[y for x in items for y in [x]]")
you will see that the list [x] is never actually created, and the for y
loop is turned into just an assignment to y.
But this is a CPython implementation detail, not a language
promise, so it may not apply to other Python implementations.
[...]
> We are well-used to reading parenthesized expressions, though.
Just because we're used to them doesn't make them easy to read.
If only 14th century mathematicians had discovered reverse Polish
notation, instead of using + as a short-hand for the Latin "et" (and),
all those stupid internet memes arguing about the value of
6รท2(2+1)
(which is ambiguous in standard maths notation, valid answers are 1 or 9)
would be obsolete. We wouldn't need brackets around expressions, parsers
would be much simpler, and big complex expressions with lots of function
calls would be much easier to understand.
On the other hand, slice notation (which is nice) would seem bizarre.
And currying in Haskell would be much harder.
> It's also not obvious to me that the often awkward comprehension
> syntax that puts the element-wise transformation first isn't
> frequently optimal.
My brain can't parse that sentence. Are you for it or against that
"often awkward comprehension syntax"?
> In
>
> log(gdp) for gdp in gdpseries
>
> economists don't really care about the dataflow, as it's the same in
> many many cases. We care about the log transformation, as that's what
> differentiates this model from others.
Julia (if I recall correctly) has a nice syntax for automatically
turning any function or method into an element-wise function:
# Take the log of one value.
log(gdp)
# Take the log of each value in the series.
log.(gdpseries)
--
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EAWRTHJ3RIM5NU6VNKSLVASGL6DU452K/
Code of Conduct: http://python.org/psf/codeofconduct/
