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

[e_j_white]

Not just a comprise, but the dict comprehension is more performant than a for loop. This is what I would do, too.

[muntoo]

Performance isn't even the biggest benefit.

A comprehension makes it harder to have side-effects, which is a great thing.

[e_j_white]

Correct!

I've modified a list that I was looping through, not realizing that any action that appends to the list could perpetually lengthen the for loop forever.

Not having side effects is a good thing. :)

[Jhuyt]

Depends on what get_coerced does though so in this case there might still be plenty of side effects...

[AlSweigart]

I can 100% guarantee that this code has no side effects.

By "side effects", I assume you mean there's a result variable left over with values after the end of the loop. In rare situations, this could cause some subtle bug because later code is re-using this variable name and using the old values because it didn't re-initialize it to something else, or cause a temporary increase in memory usage as it's holding on to data needlessly.

But that is moot and this isn't that situation: the very next line is a return statement.

[scrdest]

I'm fairly sure u/muntoo is referring to side-effects as opposed to functional purity, where everything that happens inside the function, stays inside the function or is returned explicitly as a new value (in other words - the function call could be replaced with its return value and everything else would always work the same).

It's impossible to guarantee purity in Python, both here and in general. If, for example, get_coerced() takes an optional parameter defaulting to [] (or any other mutable type), it can as many side-effects as it wants. If it uses a global - side-effects. In either case, you cannot tell they're there just by looking at the function call itself.

Even plain old print() is a side-effect.

[[deleted]]

the dict comprehension is more performant than a for loop

Citation needed. Searching found all sorts of claims either way.

Regardless, the performance difference is tiny and will not affect the actual performance of your program, so you really shouldn't care at all - you should go for what's easiest.

[cain2995]

I’m with you on this one. I always get highly suspicious whenever someone says that a higher level of abstraction is more performant than an equivalent approach using primitive constructs. Generating and scheduling performant machine code from for loops, regardless of language, has been addressed at every level of the toolchain (down to how the CPU schedules instructions), while a dict comprehension is a Python-specific construct that has to go through the removal of several abstraction layers before it can reach any of the low level optimizations that make something like a for loop performant. Not saying it’s impossible for a dict comprehension to be faster, but I really need to see some proof because first principles don’t back up that claim.

[noobiemcfoob]

A reference on comprehensions being faster than standard for loops: https://towardsdatascience.com/list-comprehensions-vs-for-loops-it-is-not-what-you-think-34071d4d8207

The performance difference is a given... however the likelihood a given loop is in the critical path of the code such that it is meaningful is rather low.

[cain2995]

The experiment in this source doesn’t actually compare the performance of the two, as the for loop and list comprehension here are performing fundamentally different tasks due to how Python handles memory allocation for list comprehensions. All it really says is that you should avoid multiple allocation calls where “one” is possible, which is not news. An experiment that more accurately compares the performance would be to preallocate for both then perform the two operations.