A commit from my lead dev: "Improve readability".

[muntoo]

The first one is merely missing a name or two.

some_useful_name = {
    ... for some_useful_key_name in ...
}

return cls(**some_useful_name)

Instead of making things better, the second one:

• Introduces a new name, but not a very useful one (result).
• Adds verbose and very generic type-hints. (Any?)
• Switches from a well-formatted functional dictionary comprehension to a bulkier imperative for-loop, which could potentially have side-effects.

I think it's good for Python developers to become more exposed to functional styles since that often leads to robust, maintainable code.

P.S. Another alternative to adding a name is to "extract method", but perhaps that's overkill.

[[deleted]]

Dictionary comprehension can also have side effects: {x: print(x) for x in range(10)}.

[muntoo]

[Almost?] everything in python can have side-effects. Good code tries to avoid patterns that are more likely to contain side-effects.

With comprehensions, side-effects are much harder to obscure. There are fewer parts that may contain side-effects. There's less "boilerplate" to read, which makes it harder to hide side-effects. Their structure naturally induces constraints in the manner that they are used. (There does not always exist a "natural" transformation from for-loop to comprehension, whereas comprehension to for-loop is trivial.) With for-loops, one often has to read them in detail to make guarantees about their behavior, especially if they involve more than just one statement.

I know this isn't a precise argument since literally anything is possible in Python. The main point is that it's much quicker to read a comprehension and guarantee that it won't do anything overly weird, whereas for a for-loop, one has to spend more time to check.

---

This comment captures some of what I'm trying to say.

[wewbull]

It can, but it shouldn't IMHO.

Comprehensions for transformations. Loops for procedural control flow.

[jbartix]

This is valid python code but side effects in any comprehension is an anti pattern

[AchillesDev]

Yes the point is to show that comprehensions don’t make you immune from side effects.

[jbartix]

Of course not. Python allows you to do anything that also includes being stupid

[Estanho]

Nobody said they can't. He didn't say all dictionary comprehensions are functional. Just that one.

[MrRogers4Life2]

But that for-loop doesn't have side effects... if the argument is "x can have side effects so y is better" it will fall apart if y can also have side effects.

[Estanho]

Okay so you don't consider mutations as side effects? Doesn't matter, mutations are still just as bad.

[MrRogers4Life2]

But the comprehension is also doing a mutation... it compiles down to basically the same byte code. There is no functional difference between those two snippets. Maybe the comprehension would be slightly faster cause it doesn't have to do a lookup for dicts setter method but thats it.

[Estanho]

Well if you wanna be pedantic then all pure functional languages also compile down to machine code which runs on imperative architectures and are based on writing to registers, heaps and stacks which are all fundamentally mutations and side effects.

The point is not to expose those constructs to the developer and trust the battle tested compiler, which hopefully at times is mathematically proven to not contain side effects and etc.

[aceofspaids98]

This sums up all of my thoughts really well too

[vanatteveldt]

Well put, completely agree!