[Python-ideas] Calling a function of a list without accumulating results

[Brett Cannon]

On 9/26/07, Terry Jones <terry at jon.es> wrote:
> Hi Brett
>
> | > 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 don't know. I use it maybe once every few weeks. There's a function to do
> this in Common Lisp (mapc), not that that means anything much.
>

You could try to get something that consumes a generator that just
tosses out the results into the stdlib.  That has a much lower barrier
of entry than new syntax.

> | 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.
>
> I don't know the answer to this either. I imagine it's a matter of tacking
> an optional "for ..." clause onto the end of an expression. The "for ..."
> part can certainly be handled (is being handled already), so I think it
> might not be too hard - supposing there is already a non-terminal for the
> "for ..." clause.
>
> | > 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.
>
> I tend to agree, but the language supports the more concise form for both
> list comprehension and genexps, so there must be a fair number of people
> who thought it was a win to allow the compact form.
>

Yes, but it was specifically for the list building idiom.

> | I think "force" is rather strong wording for "choice".
>
> OK, how about "lack of choice"?  :-)
>
> Seriously (to take an example from the Python pocket ref page 24), you do
> have the choice to write
>
>     a = [x for x in range(5) if x % 2 == 0]
>
> instead of
>
>     a = []
>     for x in range(5):
>         if x % 2 == 0:
>             a.append(x)
>
> but you don't have a (simple) choice if you don't want to accumulate
> results.  I'm merely saying that I think it would be cleaner and more
> consistent to allow
>
>     print(x) for x in range(5) if x % 2 == 0
>
> instead of having the non-choice but to write something like
>
>     for x in range(5):
>         if x % 2 == 0:
>             print x
>
> Yes, I (and thank you for it) could now use your suggested for _ in ...:
> pass trick, but that's not really the whole point, to me. If the language
> can be made simpler and more consistent, I think that's generally a good
> thing.
>

But it could be said is not simpler as there is now a new type of
statement that previously was always an expression (this would have to
be a statement as the whole point of this idea is there is no return
value).

> I know, I don't know anything about the implementation. But this is an
> ideas list.
>

Right, which is why this conversation has gone on without someone
flat-out saying it wasn't going to happen like on python-dev.  =)  But
at some point the idea either needs to seem reasonable to enough to
try to move forward or to just let it go.  And at this point I have
said what it will take to take it to the next level if you care enough
as I doubt any of the core developers will go for this enough to carry
it on their own.

> | Heck, I would vote to ditch listcomps for ``list(genexp)`` had genexps
> | come first and have the options trimmed down even more.
>
> Me too. But even if that eventuated, I'd _still_ propose allowing the
> unadorned genexp, for the case where you don't want the results.
>
> | 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
> | this.
>
> Understood.
>
> Thanks,

Welcome.  Thanks for bringing the idea up!

-Brett