Hello.

I noticed there is speed difference between

  a = [0,] # list
  a[0] # fast

and

  a = (0,) # tuple
  a[0] # slow

while solving ICPC puzzle with Python.

I thought this is wierd because, indeed tuple is readonly, there is no conceptual difference between list and tuple when 'extract' item from them.

After investigation, I found this difference comes from the shortcut for list on ceval.c (BINARY_SUBSCR).

Is it valuable to put shortcut for tuple too? I'll attach the patch for release-maint25 branch. Thank you.

It would be helpful to get some statistics on how often this occurs: of all case of BINARY_SUBSCR, how man refer to tuples, how many to lists, and how many to other objects?

To get some data, you can measure a run of a test suite, or a run of IDLE, or of compileall.

I recommend against this.

Any additional specialization code will necessarily slow down other cases handled by PyObject_GetItem.  So, the merits of speeding-up tuple indexing need to be weighed against the costs (slowing down other code and the excess loading of ceval.c with specialization code).

Also, I reject the premise that there is no conceptual difference between list and tuple indexing.  The former is a primary use case for lists and the latter is only incidental to tuple use cases (see the endless discussions on python-dev and comp.lang.python about why tuples are not to be regarded as immutable lists and in fact have a different intended set of uses).

Sorry, I want to withdraw this.

Python/lib/test/testall.py
===> list: 2541719, tuple: 620815, other: 6174214

The ratio of tuple seems relatively low.
File Added: statistics.patch

>see the endless discussions on python-dev...

Thank you, rhettinger. I'm interested in it. I'll see them.