Hacker News Reader

Comment by bilsbie | Hacker News Reader

When is that coming? Yes the error messages are confusing in a big list comprehension.

Will be in the 3.11 release: https://docs.python.org/3.11/whatsnew/3.11.html#new-features

Whenever I nest a list comprehension I feel dirty anyway, I wonder if a better error message will help solve something that is just hard to grasp sometimes.

All list comprehensions should error with message "FATAL PARSE ERROR: Will you really understand this in six months?"

If people complain about Rust's borrow checker already...

List comprehensions should be used for making quick lists that contain simple calculations or filters.

Anything more will come back to bite you later.

Something like this I find ok (just a filter):

    [x for x in y if x is not z]

Sometimes though, facilitated by Jupyter's notebooks making executing as you build the code very easy, I create a beast like this:

    [os.path.join([x for x in y if x is not z]) + '/bin' for a in b if 'temp' not in a]

Yes this is fictional and probably contains an error but you get the point, you can filter lists of lists like this, but it's really unfriendly to anyone trying to understand it later.

"Debugging is twice as hard as writing the code in the first place. Therfore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Rajanand

Although, personally, I enjoy python list comprehensions.

I believe that quote about debugging being twice as hard as coding is by Brian Kernighan.

https://en.m.wikiquote.org/wiki/Brian_Kernighan

Maybe, I grabbed the first matching quote I found. I can't attribute it on my own.

No sweat. I’m a quote nerd so it jumped out at me

Not even with nesting— as soon as it's long enough that I'm breaking it into multiple lines, I'm immediately like, okay this is long enough to just be a normal for-loop, or maybe a generator function. But it doesn't need to be a list comprehension any more.

Big list comprehensions cause confusion in many ways. KISS is crucial with them.

I agree. The rule of thumb I follow is that if the list comp doesn't fit on one line, whatever I'm doing is probably too complicated for a list comp.

But why? The only reason is that error messages are awful and intermediate values can't be named. There is in principle no reason why list comprehension need to be worse than straight line for loops. The deciding factor to chose betwee the two should be whether I'm writing something for side effects as opposed to for its value.

You just listed two very good reasons: Intermediate values can't be named, and error messages are awful.

In a way it's a nice incentive not to nest too much (I have that tendency too)

Hold my beer!

https://i.redd.it/8waggyjyyle51.png

Hold mine :D https://github.com/anchpop/genomics_viz/blob/master/genomics...

That's one expression because it used to be part of a giant comprehension, but I moved it into a function for a bit more readability. I'm considering moving it back just for kicks though.

My philosophy is: if you're only barely smart enough to code it, you aren't smart enough to debug it. Therefore, you should code at your limit, to force yourself to get smarter while debugging

That code is fine in my book, there's more static code than for-comp and it's at work 3 level deep with no hard coupling between levels. Also well spaced and worded.

Yours is nice and readable. Parents' one is not, but it feels like the indentation is deliberately confusing. I'd lay it out like so:

   tags = list(set([
     nel
     for subli in [
       mel
       for subl in [
         [[jel.split('/')[2:] for jel in el] 
         for el in classified
       ]
       for mel in subl 
     ]
     for nel in subli
     if nel
   ]))

Still not very readable, tho. But that's largely due to Python's outputs-first sequence comprehension syntax being a mess that doesn't scale at all.

Side note: one other thing I always hated about those things in Python is that there's no way to bind an intermediary computation to a variable. In C# LINQ, you can do things like:

   from x in xs
   let y = x.ComputeSomething()
   where y.IsFoo && y.IsBar
   select y

In Python, you have to either invoke ComputeSomething twice, or hack "for" to work like "let" by wrapping the bound value in a container:

   y
   for x in xs
   for y in [x.ComputeSomething()]
   if y.IsFoo and y.IsBar

It's not just about not repeating yourself or not running the same code twice, either - named variables are themselves a form of self-documenting code, and a sequence pipeline using them even where they aren't strictly needed can be much more readable.

Does the new walrus := in python solve your problem?

The official name is assignment expression, which can be good to know to find documentation. Here's the PEP: https://peps.python.org/pep-0572/

Curiously, searching the docs for "walrus" (https://docs.python.org/3/search.html?q=walrus) yields exactly the results you need, but searching for "assignment expression" yields the previous results mixed a lot of other results due to the word "expression".

Not really; where would you put it inside the []?

In the example from the end of the earlier post:

   y
   for x in xs
   if (y:=x.ComputeSomething()).IsFoo and y.IsBar

I suppose that works, although readability is not great, to put it mildly.

Much better would be

[(y:=x.ComputeSomething()) for x in xs if y.IsFoo and y.IsBar]

That doesn't work, because that first subexpression is evaluated last, after "if".

For another example of how to use the walrus operator, I use it multiple times in the code I linked a few comments up

> But that's largely due to Python's outputs-first sequence comprehension syntax being a mess that doesn't scale at all.

Choices like wrapping a set constructor around a list comprehension rather than just using a set comprehension don't help, neither does using multiple nested no-transformation comprehensions laid out that way.

By hand, on mobile, I think this reduces to (assuming “from itertools import chain” in the file header):

   tags = list({
     nel
     for subli in chain.from_iterables(chain(
       [[jel.split('/')[2:] for jel in el] 
       for el in classified))
     for nel in subli
     if nel
   })

Since it's all generator expressions internally anyway, an intermediate doesn't actually add appreciable (any?) runtime overhead but does make the code more readable:

    ys = (x.ComputeSomething() for x in xs)
    result = [y for y in ys if y.isFoo and y.isBar]

https://www.reddit.com/r/ProgrammerHumor/comments/uosex4/no_...

I don't think this is bad code. Maybe not the most Pythonic in the imperative sense, but certainly you could come across such constructs in languages that are more oriented towards functional programming. This could also be solved in a more readable manner by having a generator pipeline, though it would be a good idea to see what the performance of chained generators is like in your version and flavour of Python.

It's “not even” using for nesting in list comprehensions. This kind of thing:

   [x for stop in range(5) for x in range(stop)]

Reply on news.ycombinator.com