[jakear]

In line with this, list comprehensions are one area of python I find particularly clunky. They work fairly well for a single map or filter operation, alright for both mapping and filtering, and are absolutely unreadable for anything more complicated. A big part of this in my opinion is how they scramble the flow. Instead of taking a piece of data and performing successive operations on it, both in logic and in syntax, you have their 'literate' mess that requires you to start reading in the middle of the line and alternate moving your cursor back and forth.

Consider:

getNumbers() .map(x => x×2) .filter(x => x % 6 == 0) .map(x => x^2)

get numbers. double them. filter for divisibility by 6. square them.

versus

[x^2 for x in x×2 for x in getNumbers() if x % 6 == 0]

get the square of the doubles version of getNumbers values, but only if those doubles are dividable by 6. But wait are the doubles dividable by 6 or the squares?

Maybe some people are fine with looking at what operations are being performed on the data before even knowing what the data itself is, but that for me seems incredibly backwards. Plus it also gives rise to order of operations ambiguities. Nobody could mistake the ordering in JS, but I honestly have no clue how that python would evaluate.

(using carats because hn cant format code)

Edit- This came to mind because of a flattening list comprehension I encountered earlier today:

#flatten the lists

flattened_list = [y for x in list_of_lists for y in x]

I've spent quite some time staring at this and I still have no clue what it's actually doing. I've never had that with JS operator chains.

[pansa2]

Python’s list comprehension syntax is based on the set-builder notation from mathematics. However, I think it would have been better to break with tradition and use a different order, one which matches the order of the equivalent nested loops:

    flattened_list = [for x in list_of_lists: for y in x: y]

This is essentially the same re-arrangement that was made in C#‘s LINQ: it uses from-where-select instead of SQL’s select-from-where.

[dkersten]

Isn’t set builder notation done in the opposite direction at least? Ie given these things which are elements of blah, take these values. In Python it’s reverse, which makes sense in English but is harder to read as a sequence of steps: take these values from this set but only if... Kinda like SQL: select from where

I prefer it as a sequence of steps that get performed one after the other like a pipeline.

[jakear]

This looks nice for this case but I don’t think filter would work properly. JS is much more similar to Linq and people seem to love linq. I don’t know of anyone else that does it like python, but plenty do it like JS. For me that tells you all you need to know about whether it’s actually a good idea.

Edit: SQL does it a bit like python and it’s a massive pain in my opinion (and the opinions of many others I’ve talked to). Msft agreed so they made Kusto which does it like JS and everyone I’ve spoken with vastly prefers it.

(Work at msft, no info on the actual business reasons behind kusto, etc etc.)

[jletts]

map(lambda x:x^2, filter(lambda x:x%6==0, map(lambda x: x*2, getNumbers())))

Would probably be a more pythonic way to do that, avoiding list comprehensions. Easier to read with added lines and indentation.

But tbf I do appreciate the ability to chain operations in JS without subclassing objects like list.

[dagw]

Funny how 'pythonic' can mean different things to different people. I've been developing in python on and off for the best part of a decade, and in my world comprehensions are considered far more 'pythonic' than map/filter/lambda.

[jakear]

Also this is still confusing because you need to read it backwards. Pipelines are just better in every way, if you ask me.

[jakear]

You’re saying it’d be more Pythonic to not use list comprehensions? I find that doubtful.