The reported “speed of construction” ratio only holds for constant tuples (ones whose items are expressed by literals). Observe carefully (and repeat on your machine — you just need to type the commands at a shell/command window!)…:
$ python3.1 -mtimeit -s'x,y,z=1,2,3' '[x,y,z]'
1000000 loops, best of 3: 0.379 usec per loop
$ python3.1 -mtimeit '[1,2,3]'
1000000 loops, best of 3: 0.413 usec per loop
$ python3.1 -mtimeit -s'x,y,z=1,2,3' '(x,y,z)'
10000000 loops, best of 3: 0.174 usec per loop
$ python3.1 -mtimeit '(1,2,3)'
10000000 loops, best of 3: 0.0602 usec per loop
$ python2.6 -mtimeit -s'x,y,z=1,2,3' '[x,y,z]'
1000000 loops, best of 3: 0.352 usec per loop
$ python2.6 -mtimeit '[1,2,3]'
1000000 loops, best of 3: 0.358 usec per loop
$ python2.6 -mtimeit -s'x,y,z=1,2,3' '(x,y,z)'
10000000 loops, best of 3: 0.157 usec per loop
$ python2.6 -mtimeit '(1,2,3)'
10000000 loops, best of 3: 0.0527 usec per loop
I didn’t do the measurements on 3.0 because of course I don’t have it around — it’s totally obsolete and there is absolutely no reason to keep it around, since 3.1 is superior to it in every way (Python 2.7, if you can upgrade to it, measures as being almost 20% faster than 2.6 in each task — and 2.6, as you see, is faster than 3.1 — so, if you care seriously about performance, Python 2.7 is really the only release you should be going for!).
Anyway, the key point here is that, in each Python release, building a list out of constant literals is about the same speed, or slightly slower, than building it out of values referenced by variables; but tuples behave very differently — building a tuple out of constant literals is typically three times as fast as building it out of values referenced by variables! You may wonder how this can be, right?-)
Answer: a tuple made out of constant literals can easily be identified by the Python compiler as being one, immutable constant literal itself: so it’s essentially built just once, when the compiler turns the source into bytecodes, and stashed away in the “constants table” of the relevant function or module. When those bytecodes execute, they just need to recover the pre-built constant tuple — hey presto!-)
This easy optimization cannot be applied to lists, because a list is a mutable object, so it’s crucial that, if the same expression such as [1, 2, 3] executes twice (in a loop — the timeit module makes the loop on your behalf;-), a fresh new list object is constructed anew each time — and that construction (like the construction of a tuple when the compiler cannot trivially identify it as a compile-time constant and immutable object) does take a little while.
That being said, tuple construction (when both constructions actually have to
occur) still is about twice as fast as list construction — and that discrepancy can be explained by the tuple’s sheer simplicity, which other answers have mentioned repeatedly. But, that simplicity does not account for a speedup of six times or more, as you observe if you only compare the construction of lists and tuples with simple constant literals as their items!_)