On 9/26/07, Terry Jones <terry@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 this. -Brett

Terry Jones writes:

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

Excuse me?

instead of

for x in myXlist: for y in myYlist: f(x, y)

Oh, is that what you meant?!<wink> I think the second version is much more readable, and only a few characters longer when typing.

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?

Because it is essentially not the same thing. Comprehension syntax is justified precisely when you want to generate a list value for immediate use, and all the other ways to generate that value force you to hide what's being done in an assignment deep inside a thicket of syntax. List comprehensions are Pythonic because they "look like" lists. IMHO, anyway. OTOH, in Python, control syntax always starts with a keyword. A naked comprehension just doesn't look like a control statement to me, it still looks like an expression. I don't know if that's un-Pythonic, but I do like the multiline version better.

I think these are decent arguments. It's simply the full succinctness and convenience of list comprehensions, without needing to accumulate results.

But succintness and convenience aren't arguments for doing something in Python as I understand it. Lack of succintness and convenience may postpone acceptance of a PEP, or even kill it, of course. But they've never been sufficient for acceptance of a PEP that I've seen.

On 9/26/07, Terry Jones <terry@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 this. -Brett

Terry Jones writes:

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

Excuse me?

instead of

for x in myXlist: for y in myYlist: f(x, y)

Oh, is that what you meant?!<wink> I think the second version is much more readable, and only a few characters longer when typing.

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?

Because it is essentially not the same thing. Comprehension syntax is justified precisely when you want to generate a list value for immediate use, and all the other ways to generate that value force you to hide what's being done in an assignment deep inside a thicket of syntax. List comprehensions are Pythonic because they "look like" lists. IMHO, anyway. OTOH, in Python, control syntax always starts with a keyword. A naked comprehension just doesn't look like a control statement to me, it still looks like an expression. I don't know if that's un-Pythonic, but I do like the multiline version better.

I think these are decent arguments. It's simply the full succinctness and convenience of list comprehensions, without needing to accumulate results.

But succintness and convenience aren't arguments for doing something in Python as I understand it. Lack of succintness and convenience may postpone acceptance of a PEP, or even kill it, of course. But they've never been sufficient for acceptance of a PEP that I've seen.