4 ms·

This always feels odd to me. It would seem a fairly straight forward optimization of the interpreter to special case the different types that it can reduce. T

by taeric 17d ago

This always feels odd to me. It would seem a fairly straight forward optimization of the interpreter to special case the different types that it can reduce. That is, why couldn't they have done the essentially same trick that you reference for += with reduce?

kelipso 17d ago
[flagged]
justonceokay 17d ago
That sounds nice but in practice it’s probably not super helpful. Yes you could make a special case for reducing “+” over integers. But in python you can generally not promise that all the inputs are strictly integers, and you can’t even promise that your “+” function has no side effects.
bmandale 17d ago
There is no such trick. Python is only now getting those sort of JIT style optimizations, and that one in particular still hasn't hit. Do not use += on strings in a loop unless you are certain the iteration count will be small. There is an optimization for lists, and maybe that's what GP is remembering. l += is functionally different from l = l +. The former mutates l, whereas the latter creates a new l. The difference matters when the line above is m = l. The mutation version will mutate m as well (they're the same reference), the creates new version will not. This optimization can just as easily turn into a footgun if the programmer is unaware of it, and in that sense is unpythonic.
- Maxatar 17d ago
  Python has optimized string appending in the form of: s = s + "foo" and s += "foo" Since 2005 with the release of Python 2.4: https://docs.python.org/3/whatsnew/2.4.html#optimizations https://docs.python.org/3/whatsnew/2.4.html#optimizations
- kenferry 17d ago
  I’m not a fan of this kind of “fancy” optimization anyway. It’s too fragile. I may make some innocuous change, now the compiler cannot recognize the pattern and performance falls off the cliff. I’d rather have the reliabile performance than the absolute fastest possible result. Then if there’s an issue I can catch and fix it reliably with profiling, not deal with a heisenbug based on whether the compiler can match the pattern.

by taeric 17d ago

kelipso 17d ago

[flagged]

justonceokay 17d ago

That sounds nice but in practice it’s probably not super helpful. Yes you could make a special case for reducing “+” over integers. But in python you can generally not promise that all the inputs are strictly integers, and you can’t even promise that your “+” function has no side effects.

bmandale 17d ago

There is no such trick. Python is only now getting those sort of JIT style optimizations, and that one in particular still hasn't hit. Do not use += on strings in a loop unless you are certain the iteration count will be small. There is an optimization for lists, and maybe that's what GP is remembering. l += is functionally different from l = l +. The former mutates l, whereas the latter creates a new l. The difference matters when the line above is m = l. The mutation version will mutate m as well (they're the same reference), the creates new version will not. This optimization can just as easily turn into a footgun if the programmer is unaware of it, and in that sense is unpythonic.

Maxatar 17d ago
Python has optimized string appending in the form of: s = s + "foo" and s += "foo" Since 2005 with the release of Python 2.4: https://docs.python.org/3/whatsnew/2.4.html#optimizations https://docs.python.org/3/whatsnew/2.4.html#optimizations
kenferry 17d ago
I’m not a fan of this kind of “fancy” optimization anyway. It’s too fragile. I may make some innocuous change, now the compiler cannot recognize the pattern and performance falls off the cliff. I’d rather have the reliabile performance than the absolute fastest possible result. Then if there’s an issue I can catch and fix it reliably with profiling, not deal with a heisenbug based on whether the compiler can match the pattern.