It very clearly does, otherwise the tests would fail.

This doesnt even work!

format() wins with concatenation where more than 2 + are used. So this one stands on border.
It's because concatenation constantly creates new string objects which are immediately discarded and this at some point is outperformed by str.format parsing.

Explaination (simplified).
'a' + 'b' + 'c' execution order is: create 'a', create 'b', concatenate to 'ab', discard 'a' and 'b', create 'c', concatenate to 'abc', discard 'ab' and 'c'. Your performance is lost on byproducts like 'ab'.

This is because in Python 3.X map returns an iterator instead a list. In general iterators in Python are "empty" after first runthrough thus min(n) tries to run on empty iterator (emptied by max) and throws an error.
Solution: use list(map(...)).

Python 3 is, in many ways, not backward compatible with Python 2. But, this kata is for Python 2.

Looks like this solution is working only for Python 2.7.6. In 3.4.3 I'm getting error: ValueError: min() arg is an empty sequence

I had no idea when I typed it. I just like it better when there are few stuff to concatenate, and I really dislike the syntax of /format/.

I suspect concatenation is slower. I just did some /timeit/ to check if that is true:

1. /format/ is indeed faster than concatenation, but not much (something like 2 to 5% faster).
2. /%/ is twice as slow as concatenation.

But I only tested this case : 2 numbers that must be stringified. I imagine that with 2 strings, concatenation might be faster. And if there are more objects to print, I imagine that /format/ would be faster.

But I still hate /format/ syntax :-) (and I even still like /%/ syntax better)

Is string concatenation faster than format() from a performance standpoint?