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

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