On 10 Jun 2013 23:54, "Roel Schroeven" <ro...@roelschroeven.net> wrote:
>
> You could do something like:
>
> new_songs, old_songs = [], []
> [(new_songs if s.is_new() else old_songs).append(s) for s in songs]
>
> But I'm not sure that that's any better than the long version.
This is so beautiful!
On 10 Jun 2013 23:54, "Roel Schroeven" <ro...@roelschroeven.net> wrote:
>
> You could do something like:
>
> new_songs, old_songs = [], []
> [(new_songs if s.is_new() else old_songs).append(s) for s in songs]
>
> But I'm not sure that that's any better than the long version.This is so beautiful!
On 11 Jun 2013 07:47, "Peter Otten" <__pet...@web.de> wrote:
>
> Fábio Santos wrote:
>
> > On 10 Jun 2013 23:54, "Roel Schroeven" <ro...@roelschroeven.net> wrote:
> >>
> >> You could do something like:
> >>
> >> new_songs, old_songs = [], []
> >> [(new_songs if s.is_new() else old_songs).append(s) for s in songs]
> >>
> >> But I'm not sure that that's any better than the long version.
> >
> > This is so beautiful!
>
> It makes me cringe.
>
> This code does spurious work to turn what is naturally written as a for loop
> into a list comprehension that is thrown away immediately. I think I'd even
> prefer this "gem"
>
> >>> evens = []
> >>> odds = [item for item in range(10) if item % 2 or evens.append(item)]
> >>> evens, odds
> ([0, 2, 4, 6, 8], [1, 3, 5, 7, 9])
>
> but if I have my way every side effect in a list comprehension should be
> punished with an extra hour of bug-hunting ;)
>
What I like so much about it is the .. if .. else .. Within the parenthesis and the append() call outside these parenthesis.
I agree it would be best written as a for loop, to increase readability and avoid confusion. I always expect list comprehensions to be used as expressions, and its use as a (single-expression) statement is rather odd.
On 11 Jun 2013 07:52, "Jonas Geiregat" <jo...@geiregat.org> wrote:
> I must disagree , this is unreadable and in my honor opinion not Pythonic at all.
> I've learned it's always better to be explicit then implicit, and this snippet of code does a lot in an implicit way.
>
(Read above)
On 11 Jun 2013 17:47, "rusi" <rusto...@gmail.com> wrote:
> [Of course I would prefer a 3-liner where the body of the for is
> indented :-) ]
Is this an aside comprehension?
On 11 Jun 2013 18:48, "Chris Angelico" <ros...@gmail.com> wrote:
>
> On Wed, Jun 12, 2013 at 3:23 AM, rusi <rusto...@gmail.com> wrote:
> > On Jun 11, 10:05 pm, Fábio Santos <fabiosantos...@gmail.com> wrote:
> >> On 11 Jun 2013 17:47, "rusi" <rustompm...@gmail.com> wrote:
> >>
> >> > [Of course I would prefer a 3-liner where the body of the for is
> >> > indented :-) ]
> >>
> >> Is this an aside comprehension?
> >
> > Eh?
>
> I know they always say "don't explain the joke", but I'll have a shot
> at it. It's somewhat like an autopsy though - you find out why it
> ticks, but in the process, you prove that it's no longer ticking...
>
> An aside comprehension is a means of generating an aside in-line, as
> an expression. In this case, Fabio believes that you were iterating
> over the smiley to generate comments about three-liners, and the
> square brackets delimit the comprehension just as they do in a list
> comprehension.
>
> It's another case of code syntax cropping up in English, like this
> example of ternary punctuation from a C++ program...
>
> //TODO?: blah blah blah
>
> That doesn't translate too well into Python though.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
That was the joke. Unfortunately I didn't have a better synonym for "aside" so it wasn't so obvious.
You could equivalently pass the generator to deque() with maxlen=0 - this consumes the iterator with constant memory usage.
We are of course firmly in the twilight zone at this point (although this can be a useful technique in general).
Cheers,
Phil
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
On 12 Jun 2013 12:43, "Roy Smith" <r...@panix.com> wrote:
>
> In article <mailman.3050.1371018...@python.org>,
> Phil Connell <pcon...@gmail.com> wrote:
>
> > > Well, continuing down this somewhat bizarre path:
> > >
> > > new_songs, old_songs = [], []
> > > itertools.takewhile(
> > > lambda x: True,
> > > (new_songs if s.is_new() else old_songs).append(s) for s in songs)
> > > )
> > >
> > > I'm not sure I got the syntax exactly right, but the idea is anything
> > > that will iterate over a generator expression. That at least gets rid
> > > of the memory requirement to hold the throw-away list :-)
> >
> > You could equivalently pass the generator to deque() with maxlen=0 - this
> > consumes the iterator with constant memory usage.
> >
> > We are of course firmly in the twilight zone at this point (although this
> > can be a useful technique in general).
>
> We've been in the twilight zone for a while. That's when the fun
> starts. But, somewhat more seriously, I wonder what, exactly, it is
> that freaks people out about:
>
> >>>> [(new_songs if s.is_new() else old_songs).append(s) for s in songs]
>
> Clearly, it's not the fact that it build and immediately discards a
> list, because that concern is addressed with the generator hack, and I
> think everybody (myself included) agrees that's just horrible.
I think someone has already said that the problem is that you're creating the list comprehension just for the side effects.
> Or, is it the use of the conditional to create the target for append()?
I particularly liked that part.