Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 21 October 2016 at 05:09, Random832 wrote: > On Tue, Oct 18, 2016, at 02:10, Nick Coghlan wrote: >> Hi, I contributed the current list comprehension implementation (when >> refactoring it for Python 3 to avoid leaking the iteration variable, >> as requested in PEP 3100

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Fri, Oct 21, 2016 at 6:09 AM, Random832 wrote: > On Tue, Oct 18, 2016, at 02:10, Nick Coghlan wrote: >> Hi, I contributed the current list comprehension implementation (when >> refactoring it for Python 3 to avoid leaking the iteration variable, >> as requested in PEP

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Tue, Oct 18, 2016, at 02:10, Nick Coghlan wrote: > Hi, I contributed the current list comprehension implementation (when > refactoring it for Python 3 to avoid leaking the iteration variable, > as requested in PEP 3100 [1]), and "comprehensions are syntactic sugar > for a series of nested for

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18.10.2016 08:23, Greg Ewing wrote: If it were a namedtuple, for example, you could write [*t for t in fulltext_tuples if t.language == 'english'] or [x for t in fulltext_tuples if t.language == 'english' for x in t] The latter is a bit unsatisfying, because we are having to make up

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18.10.2016 10:01, Daniel Moisset wrote: So, for me, this feature is something that could be covered with a (new) function with no new syntax required. All you have to learn is that instead of [*...] you use flatten(...) The main motivation is not "hey we need yet another way for xyz" but

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18 October 2016 at 07:31, Nick Coghlan wrote: > > Forcing ourselves to come up with a name for the series of values > produced by the outer iteration then makes that name available as > documentation of our intent for future readers of the code. This is a key point, that

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

> I feel like I should be honest about something else - I'm always a > little bit confused by the ordering for comprehensions involving > multiple clauses. For me, it's the fact that: > [[a for a in b] for b in ['uvw', 'xyz']] == [['u', 'v', 'w'], ['x', 'y', > 'z']] > which makes me want to write:

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18 October 2016 at 13:32, David Mertz wrote: > On Mon, Oct 17, 2016 at 7:50 PM, Random832 wrote: >> I feel like I should be honest about something else - I'm always a >> little bit confused by the ordering for comprehensions involving >> multiple

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 2016-10-17 16:35, Steven D'Aprano wrote: >and many times I have been irritated by the fact that the >one-item-per-loop invariant exists. I'm not sure whether I'm in favor of >this particular syntax, but I'd like to be able to do the kind of things it >allows. But doing them inherently

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18 October 2016 at 03:49, Random832 wrote: > On Mon, Oct 17, 2016, at 13:32, Steven D'Aprano wrote: >> This isn't a small change: it requires not >> insignificant changes to people's understanding of what list >> comprehension syntax means and does. > > Only if their

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 7:50 PM, Random832 wrote: > On Mon, Oct 17, 2016, at 22:17, David Mertz wrote: > > > [*range(x) for x in range(4)] > > > > As Paul or someone pointed out, that's a fairly odd thing to do. > > I agree with the specific example of it being an odd

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

> > For a more concrete example: > > [*range(x) for x in range(4)] > [*(),*(0,),*(0,1),*(0,1,2)] > [0, 0, 1, 0, 1, 2] > As Paul or someone pointed out, that's a fairly odd thing to do. It's the first time that use case has been mentioned in this thread. It's true you've managed to construct

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 10:33:32PM +0200, Sven R. Kunze wrote: > Sorry? You know, I am all for real-world code and I also delivered: > https://mail.python.org/pipermail/python-ideas/2016-October/043030.html Your example shows the proposed: [*(language, text) for language, text in

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:43, Sven R. Kunze wrote: > The statement about "cumbersomeness" was specific to this whole issue. Of > course, importing feature-rich pieces from the stdlib is really cool. It was > more the missed ability to do the same with list comprehensions of what

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17.10.2016 22:26, Paul Moore wrote: Certainly having to add an import statement is extra typing. But terseness was *never* a feature of Python. In many ways, a resistance to overly terse (I could say "Perl-like") constructs is one of the defining features of the language - and certainly, it's

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:30, Random832 wrote: > On Mon, Oct 17, 2016, at 16:12, Paul Moore wrote: >> And finally, no-one has even *tried* to explain why we need a third >> way of expressing this construction. Nick made this point, and >> basically got told that his

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016, at 16:12, Paul Moore wrote: > And finally, no-one has even *tried* to explain why we need a third > way of expressing this construction. Nick made this point, and > basically got told that his condition was too extreme. He essentially > got accused of constructing an

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:22, Random832 wrote: > For a more concrete example: > > [*range(x) for x in range(4)] > [*(),*(0,),*(0,1),*(0,1,2)] > [0, 0, 1, 0, 1, 2] > > There is simply no way to get there by using flatten(range(4)). The only > way flatten *without* a

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 20:35, Sven R. Kunze wrote: > P.S. It's very artificial to assume user are unable to use 'from itertools > import chain' to try to make chain() seem more cumbersome than it is. > > I am sorry but it is cumbersome. Imports are a fundamental part of Python.

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 18:32, Steven D'Aprano wrote: > On Mon, Oct 17, 2016 at 12:11:46PM -0400, Random832 wrote: > >> Honestly, it goes beyond just being "wrong". The repeated refusal to >> even acknowledge any equivalence between [...x... for x in [a, b, c]] >> and [...a...,

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17.10.2016 20:38, David Mertz wrote: Under my proposed "more flexible recursion levels" idea, it could even be: [f(x) for x in flatten(it, levels=3)] There would simply be NO WAY to get that out of the * comprehension syntax at all. But a decent flatten() function gets all the

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 9:11 AM, Random832 wrote: > Once again, this alleged simplicity relies on the chosen example "x for > x" rather than "f(x) for x" - this one doesn't even put the use of > flatten in the right place to be generalized to the more complex cases. >

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Sun, Oct 16, 2016 at 02:34:58PM +0200, Sven R. Kunze wrote: > As this discussion won't come to an end, I decided to consult my girlfriend. [...] > >>> [(i,i,i) for i in range(4)] > [(0, 0, 0), (1, 1, 1), (2, 2, 2), (3, 3, 3)] Did you remember to tell your girlfriend that a critical property

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

Actually, I agree with Marietta. I don't care whatsoever about mocking me, which was a certain element of it. I have thick skin and am confident in these conversations. The part that was probably over the line was mocking children who learn to program or those who teach them. That's a huge and

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 16/10/2016 16:41, Mariatta Wijaya wrote: Her reaction was hilarious: "Whom does he teach? Children?" I sense mockery in your email, and it does not conform to the PSF code of conduct. Please read the CoC before posting in this mailing list. The link is available at the bottom of every

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

>Her reaction was hilarious: > >"Whom does he teach? Children?" I sense mockery in your email, and it does not conform to the PSF code of conduct. Please read the CoC before posting in this mailing list. The link is available at the bottom of every python mailing list email.

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Sun, Oct 16, 2016 at 5:34 AM, Sven R. Kunze wrote: > On 16.10.2016 07:08, David Mertz wrote: > >> In case it wasn't entirely clear, I strongly and vehemently opposed this >> unnecessary new syntax. It is confusing, bug prone, and would be difficult >> to teach. > > > "Whom

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 16 October 2016 at 06:47, Chris Angelico wrote: > On Sun, Oct 16, 2016 at 3:44 PM, Greg Ewing > wrote: > > Steven D'Aprano wrote: > > > >> This thread is a huge, multi-day proof that people do not agree that > this > >> is a "reasonable"

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 16.10.2016 07:08, David Mertz wrote: In case it wasn't entirely clear, I strongly and vehemently opposed this unnecessary new syntax. It is confusing, bug prone, and would be difficult to teach. As this discussion won't come to an end, I decided to consult my girlfriend. I started

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Sun, Oct 16, 2016 at 05:14:54AM +, Neil Girdhar wrote: [Steven (me), refering to Greg] > > Because as your own email inadvertently reinforces, if sequence > > unpacking made sense in the context of a list comprehension, it would > > already be allowed rather than a SyntaxError: it is

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Sat, Oct 15, 2016 at 9:42 PM Steven D'Aprano wrote: > On Sun, Oct 16, 2016 at 12:48:36PM +1300, Greg Ewing wrote: > > Steven D'Aprano wrote: > > >Are you now supporting my argument that starring the list comprehension > > >expression isn't meaningful? > > > > The context

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Sun, Oct 16, 2016 at 3:44 PM, Greg Ewing wrote: > Steven D'Aprano wrote: > >> This thread is a huge, multi-day proof that people do not agree that this >> is a "reasonable" interpretation. > > > So far I've seen one very vocal person who disgrees, and > maybe one

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Oct 15, 2016 6:42 PM, "Steven D'Aprano" wrote: > doesn't make sense, it is invalid. Call it something else: the new > "flatten" operator: > > [^t for t in iterable] > > for example, which magically adds an second invisible for-loop to your list comps: This thread is a

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Sun, Oct 16, 2016 at 12:48:36PM +1300, Greg Ewing wrote: > Steven D'Aprano wrote: > >Are you now supporting my argument that starring the list comprehension > >expression isn't meaningful? > > The context it's in (a form of list display) has a clear > meaning for a comma-separated list of

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Sat, Oct 15, 2016 at 12:48 PM, Steven D'Aprano wrote: > Oh look, just like now: > > py> iterable = [(1, 'a'), (2, 'b')] > py> [(100, *t) for t in iterable] > [(100, 1, 'a'), (100, 2, 'b')] > > Hands up anyone who expected to flatten the iterable and get > > [100, 1,

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

Martti Kühne wrote: You brush over the fact that *t is not limited to a replacement by a comma-separated sequence of items from t, but *t is actually a replacement by that comma-separated sequence of items from t INTO an external context. Indeed. In situations where there isn't any context for

[Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Sat, Oct 15, 2016 at 10:09 AM, Steven D'Aprano wrote: > Not everything is a function. What's your point? > > As far as I can see, in *every* other use of sequence unpacking, *t is > conceptually replaced by a comma-separated sequence of items from t. If > the starred item