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

2016-10-21 Thread Nick Coghlan
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

2016-10-20 Thread Chris Angelico
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

2016-10-20 Thread Random832
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

2016-10-20 Thread Sven R. Kunze
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

2016-10-20 Thread Sven R. Kunze
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

2016-10-18 Thread Random832
On Tue, Oct 18, 2016, at 04:01, Daniel Moisset wrote: > I see some mention that flatten does not cover all cases; but correct > me if I'm wrong with this statement: > > Any case of [* for in ] could be replaced with > flatten( for in ). Where flatten is defined as > > def flatten(it): >

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

2016-10-18 Thread Paul Moore
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

2016-10-18 Thread Martti Kühne
> 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

2016-10-18 Thread Nick Coghlan
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

2016-10-18 Thread Greg Ewing
Steven D'Aprano wrote: Your example shows the proposed: [*(language, text) for language, text in fulltext_tuples if language == 'english'] which can be written as: [x for language, text in fulltext_tuples for x in (language, text) if language == 'english'] which is only ten

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

2016-10-18 Thread Brendan Barnwell
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

2016-10-18 Thread Nick Coghlan
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

2016-10-17 Thread David Mertz
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

2016-10-17 Thread Random832
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 thing to do with range, it was just an attempt to illustrate with a concrete example. >

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

2016-10-17 Thread David Mertz
> > 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

2016-10-17 Thread Steven D'Aprano
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

2016-10-17 Thread Steven D'Aprano
On Mon, Oct 17, 2016 at 11:16:03AM -0700, Brendan Barnwell wrote: > Now, personally, I don't insist on that invariant. I would > certainly like to be able to do more general things in a list > comprehension, I hear you, because I too would like to introduce a variant

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

2016-10-17 Thread Greg Ewing
Steven D'Aprano wrote: What I don't believe is: (1) that the majority of Python programmers (or even a large minority) regularly and consistently think of comprehensions as syntactic sugar for a completely unrolled list display; rather, I expect that they usually think of them as sugar for a

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

2016-10-17 Thread Paul Moore
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

2016-10-17 Thread Paul Moore
On 17 October 2016 at 21:33, Sven R. Kunze wrote: > On 17.10.2016 22:12, Paul Moore wrote: >> >> 4. Whether you choose to believe me or not, I've sincerely tried to >> understand the proposal [...] > > I think you did and I would like others to follow your example. >> >> 2. Can

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

2016-10-17 Thread Sven R. Kunze
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

2016-10-17 Thread Paul Moore
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

2016-10-17 Thread Random832
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

2016-10-17 Thread Random832
On Mon, Oct 17, 2016, at 14:38, David Mertz wrote: > What you're saying is EXACTLY 180 deg reversed from the truth. It's > *precisely* because it doesn't need the extra complication that > `flatten()` > is more flexible and powerful. I have no idea what your example is meant > to do, but the

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

2016-10-17 Thread Paul Moore
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

2016-10-17 Thread Paul Moore
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

2016-10-17 Thread Paul Moore
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

2016-10-17 Thread Sven R. Kunze
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

2016-10-17 Thread אלעזר
On Mon, Oct 17, 2016 at 9:49 PM David Mertz wrote: ... > Moreover, this "magical flatten" operator will crash in bad ways that a > regular flatten() will not. I.e. this is fine (if strange): > > >>> three_inf = (count(), count(), count()) > >>> comp = (x for x in

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

2016-10-17 Thread David Mertz
On Mon, Oct 17, 2016 at 10:32 AM, Steven D'Aprano wrote: > But if we *do* accept this syntax, then I believe that we should drop > the pretense that it is a natural extension of sequence unpacking in the > context of a for-loop-with-append (i.e. list comprehensions) and

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

2016-10-17 Thread David Mertz
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

2016-10-16 Thread Nick Coghlan
On 16 October 2016 at 14:44, 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 other

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

2016-10-16 Thread Steven D'Aprano
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

2016-10-16 Thread David Mertz
... actually, thank you Sven (but Mark also. And all the contributors to the discussion, even those I disagree with). On Oct 16, 2016 10:47 AM, "David Mertz" wrote: > Actually, I agree with Marietta. I don't care whatsoever about mocking me, > which was a certain element of it.

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

2016-10-16 Thread David Mertz
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

2016-10-16 Thread Mark Lawrence via Python-ideas
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

2016-10-16 Thread Mariatta Wijaya
>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

2016-10-16 Thread David Mertz
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

2016-10-16 Thread Ivan Levkivskyi
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

2016-10-16 Thread Sven R. Kunze
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

2016-10-16 Thread Steven D'Aprano
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

2016-10-15 Thread Neil Girdhar
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

2016-10-15 Thread Chris Angelico
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

2016-10-15 Thread Greg Ewing
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 other who isn't sure. This proposal only makes even a little bit of sense if you imagine list

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

2016-10-15 Thread David Mertz
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

2016-10-15 Thread Steven D'Aprano
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

2016-10-15 Thread Martti Kühne
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

2016-10-15 Thread Greg Ewing
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

2016-10-15 Thread Martti Kühne
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