"However, the slight difference in syntax makes Python dramatically easier to read and write"

Please prove it.

The evidence is in the usage. As I said, Javascript decided it was a bad idea, despite its popularity in Python.

Your phrasing is a little aggressive, so I'm guessing this is one of those discussions where there's no real chance to change your mind, but I'll give it a shot.

Consider one of the most friendly languages, SQL. Python comprehensions follow the same pattern as SQL.

    SELECT expression FROM table WHERE condition
    [expression for name in sequence if condition]

Javascript put the expression at the end.

    [for (name of iterable) if (condition) expression]

Putting the expression first makes the language more declarative. The easiest languages -- SQL, HTML, etc. -- are declarative, not procedural or functional.

> The evidence is in the usage...

It's possible it was not adopted because there's a cost involved in every feature that has inconsistent support across runtime. The benefit needs to outweigh that cost.

> Putting the expression first makes the language more declarative

The case for a specific order makes less sense in a declarative language, not more.

And:

[1,2,3,4].map((x) => x * 2)

Doesn't seem substantially more or less declarative than:

[x * * 2 for x in range(1,5)]

to me. If anything, the latter example asks more of the reader because it requires an awareness of case-specific semantics.

And overall, it's simply never been clear to me what comprehensions buy in terms of readability or semantics over map/reduce/etc, and given JS cultural buy-in on some imported concepts from FP, my guess is that the marginal benefit just didn't seem worth the cost rather than it being a misstep in the specific proposed JS syntax.

Also: SQL has its points, but it's not a language I'd generally describe as easiest. Declarative DSLs tend to be largely convenient only in their domain. It may be worth admitting SQL to this discussion I suppose given the overlap between its domain and map or foreach like concepts, but is it really strictly easier to reason about how to do something this particular thing in it (and what it's actually doing) than either Python or JS? I don't think that's as straightforward an argument as you seem to have assumed.

Listen to how people who don't program describe the task of transforming each element of something. In my experience they often say something along the lines of, "I want y for each x in z," rather than, "For each x in z, I want y." The latter is more common among people who've been programming in certain languages, not the average person. I don't have systematic data collection for this, just personal experience. But the Javascript decision adds some evidence, in my view.

> it's simply never been clear to me what comprehensions buy in terms of readability or semantics over map/reduce/etc

Ask some random person off the street to read your source code. They're more likely to get the gist of code using comprehensions than code using map/reduce/etc.

> SQL ... convenient only in [its] domain.

Which is exactly the domain we're talking about when discussing comprehensions.

> Listen to how people who don't program describe the task of transforming each element of something. In my experience they often say something along the lines of, "I want y for each x in z," rather than, "For each x in z, I want y."

If we're really at the point where we're arguing between which clause order (among other potential variations in expression) is more natural across most natural language speakers, that should about wrap it up.

But to the extent that it doesn't, this assertion has the merit that it sounds like an empirically verifiable position.

> Ask some random person off the street to read your source code.

Which is worth considering, I suppose, in situations where the relevant software is being built by people being brought in off the street.

> [SQL] is exactly the domain we're talking about when discussing comprehensions.

"Exactly" overstates the case. As I said above, I recognize it's a related domain, but there's plenty of things that are easier to do with Python or Javascript than they are in SQL, even specifically with operations over every tuple in a set.

And again, declarative == easier is overgeneral assumption. Take Prolog, for example. Definitely domain-overlapped with SQL, often a poster child for declarative. I quite like it myself, but it's not always a hit at parties. Even hackathon parties.

> empirically verifiable

I'd love to see the data.

> software ... built by people ... off the street

Programming is such a rapidly growing field that I think the majority of software will be written by programmers with less than 1 year experience. For a time, anyway. Maybe in 20 or 30 years the growth will slow.

> The evidence is in the usage.

That's not what I asked for. You're asking me to accept a concrete proposition that I obviously don't. To sway me, I'd like proof, not a single example labeled evidence.

Proof? Describe what proof means to you.

The fact that Javascript decided not to adopt the syntax seems like good evidence to me.

I'm not asking you to do anything. I'm offering you some insights. Normally people pay me for my time, but I suppose I feel like volunteering at the moment.

The fact that python decided to use a different syntax doesn't prove that it was good either.

What you volunteered to me is a mirror image of an argument you think I presented, then suggested my version was wrong.

But I'm not actually advocating for JavaScript syntax here. I just don't think list comprehension syntax, as presented by python, is particularly better in comparison. You said it's much better, then demanded that I agree with you.

Demanded? I ain't demanding shit. Certainly not of a stranger on the internet.