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 [1]), and "comprehensions
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 3100 [1]), and "comprehens
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 an
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 an
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
"
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):
> ret
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 is frequently missed w
On 17 October 2016 at 21:22, Random832 wrote:
>
> No, it's not.
>
> 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 equivalent flatten for that is:
flatten(r
> 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:
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 clauses.
>
> Me too! I get the order of nested
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 charact
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 requir
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 understanding is limited to
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 thing to do with
> range, it
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.
> I
>
> 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 some
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 fulltext_t
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
comprehensio
David Mertz wrote:
>>> three_inf = (count(), count(), count())
>>> comp = (x for x in flatten(three_inf))
>>> next(comp)
0
>>> next(comp)
1
It's hard to see how that won't blow up under the new syntax (i.e.
generally for all infinite sequences).
It won't blow up, because * in a generator
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
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 is
> possible with
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 someone summarise t
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
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 condition was too extreme. He es
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 someone summarise the *other* arguments for the proposal?
I for one think it's just res
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 impossibl
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 actu
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 generator expression can serve th
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. How are they "cumb
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..., ...b..., ...c...] tru
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 flexibili
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 flatten(three_inf))
> >>> next(c
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 accept
> that it will be s
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.
> You'd need list(flatten(f(x)
On Sun, Oct 16, 2016 at 9:06 PM, Nick Coghlan wrote:
> Remember that what we're arguing about is that existing instances of:
>
> [x for subiterable in iterable for x in subiterable]
>
> [...] would be easier to read and maintain if they were instead written as:
>
> [*subiter for subiter in it
But the proposal has explicit syntax that point the reader to the fact that
the invariant doesn't hold. Same as other unpacking occurences:
[x, *y]
The invariant does not hold. And that's explicit.
Elazar
בתאריך יום ב׳, 17 באוק' 2016, 21:16, מאת Brendan Barnwell <
brenb...@brenbarn.net>:
> On
On 2016-10-17 10:32, Steven D'Aprano wrote:
In a list comprehension, we expect the invariant that the number of
items produced will equal the number of loops performed. (Less if there
are any "if" clauses.) There is one virtual append per loop. You cannot
get the behaviour you want without breaki
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 understanding is limited to a sequence of tokens that it
supposedly expands to [
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..., ...b..., ...c...] truly makes it difficult for me to
> accept some people's _sin
On Mon, Oct 17, 2016, at 00:06, Nick Coghlan wrote:
> Remember that what we're arguing about is that existing instances of:
>
> [x for subiterable in iterable for x in subiterable]
>
> or:
>
>list(itertools.chain.from_iterable(iterable))
>
> would be easier to read and maintain if they we
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 who isn't sure.
"Language desi
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 of
On Sun, Oct 16, 2016 at 03:02:55PM +0200, Ivan Levkivskyi wrote:
> What I have learned from this megathread is that the syntax [*foo for foo
> in bar]
> is proposed as a replacement for a one-liner itertools.chain(*[foo for foo
> in bar]).
If people take away nothing else from this thread, it sho
... 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. I have thick skin
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 gre
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 pytho
>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.
https://www.python.org
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 does he teach? Chil
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" interpretation.
> >
> >
> > So far I've seen one very v
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 with
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 intent
On Oct 15, 2016 9:45 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 other who isn't sure.
In case it wasn
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 it's in (a form of lis
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 other who isn't sure.
>
And wh
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
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 lot of work to try to
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 valu
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 values, so there
is a reasonable interpretation that it *could* be given.
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, 'a', 100, 2, 'b']
>
> in
On Sat, Oct 15, 2016 at 11:36:28PM +1300, Greg Ewing wrote:
> Indeed. In situations where there isn't any context for
> the interpretation of *, it's not allowed.
You mean like in list comprehensions?
Are you now supporting my argument that starring the list comprehension
expression isn't mean
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
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 is on the left-hand si
62 matches
Mail list logo
