[Python-ideas] Calling a function of a list without accumulating results
brett at python.org
Thu Sep 27 02:43:49 CEST 2007
On 9/26/07, Terry Jones <terry at jon.es> wrote:
> Hi Brett & Adam
> Thanks for the replies.
> | Only after the list is completely constructed. List comprehensions
> | are literally 'for' loops with an append call to a method so without
> | extending the peepholer to notice this case and strip out the list
> | creation and appending it is not optimized.
> | > A possible syntax change would be to allow the unadorned
> | >
> | > f(x) for x in mylist
> | >
> | > And raise an error if someone tries to assign to this.
> | Go with the 'for' loop as Adam suggested. I just don't see this as
> | needing syntax support.
> I think there are two arguments in its favor.
> The first is the same as one of the arguments for providing list
> comprehensions and generator expressions - because it makes common
> multi-line boilerplate much more concise.
OK, the question is how common is this. I personally don't come
across this idiom often enough to feel the need to avoid creating a
listcomp, genexp, or a 'for' loop.
> There's a certain syntax that's allowed in  and () to make list
> comprehensions and generator expressions. I'm suggesting allowing exactly
> the same thing, but with no explicit grouping wrapped around it.
But are you sure Python's grammar could support it? Parentheses are
needed for genexps in certain situations for disambiguation because of
Python's LL(1) grammar.
> The trivial case I posted isn't much of a win over the simple 2-line
> alternative, but it's easy to go to further:
> f(x, y) for x in myXlist for y in myYlist
> instead of
> for x in myXlist:
> for y in myYlist:
> f(x, y)
> and of course there are many more examples.
Right, but the second one is so much easier to read and comprehend.
> The second argument is one of consistency. If list comprehensions are
> regarded as more pythonic and the Right Way to code in Python, I'd make the
> same argument for when you don't happen to want to keep the accumulated
> results. Why force programmers to use two coding styles in order to get
> essentially the same thing done?
I think "force" is rather strong wording for "choice". The point is
the 'for' loop is the standard solution and there just happens to be a
shorthand for a common case. You shouldn't view listcomps as being on
the same ground as a 'for' loop.
> I think these are decent arguments. It's simply the full succinctness and
> convenience of list comprehensions, without needing to accumulate results.
They are decent, but not enough to warrant adding special support in
my opinion. Heck, I would vote to ditch listcomps for
``list(genexp)`` had genexps come first and have the options trimmed
down even more.
And if you are doing this to just toss out stuff you can do something like::
for _ in (f(x) for x in anylist): pass
No accumulating list, one line, and you still get your genexp syntax.
Basically, unless you can go through the stdlib and find all the
instances of the pattern you want to prove it is common enough to
warrant support it none of the core developers will probably go for
More information about the Python-ideas