Christopher King wrote:

...

This syntax is already taken for generator expressions.

How?

Your proposed syntax for tuple comprehensions: (expr for x in iterable) Syntax already used for generator expressions: (expr for x in iterable) -- Steven

On Tue, Oct 18, 2011 at 2:57 PM, Ben Finney wrote:

More precisely, the parens are not part of the syntax for generator expressions.

Yes they are. There's just an exception in the grammar to make it so that the *existing* parens that indicate a function call also count when a generator expression is the sole positional argument. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Tue, Oct 18, 2011 at 3:47 PM, Ben Finney wrote:

Nick Coghlan writes:

...

On Tue, Oct 18, 2011 at 2:57 PM, Ben Finney wrote:

...

More precisely, the parens are not part of the syntax for generator expressions.

Yes they are.

I had the impression that they could appear as a bare expression without parens. But the Python interpreter doesn't support that impression, so I guess I was wrong. Thanks for pointing it out.

You may have been thinking of yield expressions, where the parentheses aren't technically part of the syntax, but are still mandatory in a lot of places to avoid visual ambiguity. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On 2011-10-10, at 04:51 , Mathias Panzenböck wrote:

...

('banana','loganberry','passion fruit')

...

...

...

import operator (operator.concat(_, weapon.strip()) for weapon in freshfruit) 'bananaloganberrypassion fruit'

In addition to all previous remarks about the generator expression, what's wrong with the following?

...

...

...

import operator xs=['banana', 'loganberry', 'passion fruit'] reduce(operator.concat,(x.strip() for x in xs))

I'm guessing the issues (from the original mail) are that it does not benefit from the "concision" ascribed to comprehension (though that concision really is mostly when there isn't a mapping and/or filtering method readily available), and that `reduce` moved to `functools` in Python 3 And of course, for this precise expression you could just do this:

...

...

''.join(x.strip() for x in xs)

On Mon, Oct 17, 2011 at 7:57 PM, Christopher King wrote: ..

...

...

...

...

reduce(operator.concat,(x.strip() for x in xs))

To long for something so simple

.. and how would tuple comprehensions help in this case? A shorter expression would be

...

...

''.join(x.strip() for x in xs)

For your data, .strip() seems redundant, so

...

...

''.join(xs)

would achieve the same result. Finally, a more realistic application would want to separate the data somehow:

...

...

','.join(xs)

Hi, All, As Masklinn pointed out, the issue is that there's no concise way to accumulate or compress an iterable without resorting to the use of the reduce() function. To answer Greg's point, it's not like list comprehensions cover all the cases allowed by the concept of mapping. There are cases, such as when the construction rule is too complicated, where comprehensions cannot be applied. Given that, why not explore the idea of if and how we can make (simple) reductions more readable. To me, the tricky part was resolving the ambiguity between a map and reduce expression in the comprehension. Given that the first argument to the reduce() function is the accumulated value, which is something that the map() function doesn't need, I felt that we could use that to make the distinction between the two in the comprehension. In particular, if the expression in the comprehension refers to the accumulated value (through the "_" variable), then it could treat it as a reduction as opposed to a mapping. Here's another example to illustrate the desired behavior, which basically adds a list of numbers (without resorting to the use of a reduce()):

...

...

numbers=[1,2,3,4,5] [_+number for number in numbers] 15

Just to clarify, we're just talking about some syntactic sugar here, nothing more, nothing less. Best Regards, Karthick Sankarachary On Mon, Oct 10, 2011 at 2:26 PM, Greg Ewing wrote:

Karthick Sankarachary wrote:

...

For one thing, list comprehensions don't let you create immutable sequences (such as a tuple) by design. For another, it does not provide a concise alternative to reduce() function.

There was a big discussion a while back about a syntax for reduction operations. The conclusion reached was that the concept of reduction has so many degrees of freedom that, beyond the very simple cases covered by the reduce() function, nothing is clearer than simply writing out the loop explicitly.

-- Greg

______________________________**_________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/**mailman/listinfo/python-ideashttp://mail.python.org/mailman/listinfo/python-ideas

On Tue, Oct 11, 2011 at 9:36 AM, Karthick Sankarachary wrote:

Just to clarify, we're just talking about some syntactic sugar here, nothing more, nothing less.

And the increased cognitive burden in learning the language isn't worth it. Write a nice custom reduction function (like sum, any, all, min, max, etc) and feed it a generator expression. If you really want to argue the point, please read the following first: http://www.boredomandlaziness.org/2011/02/justifying-python-language-changes... http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html And maybe this one as well: http://www.boredomandlaziness.org/2011/04/musings-on-culture-of-python-dev.h... (I guess those links may be the kind of thing that was being asked for recently when someone was wondering what kind of reaction to expect when posting suggestions to this list) Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia