On 27/08/20 3:51 am, Ricky Teachey wrote:
On Wed, Aug 26, 2020 at 11:30 AM Greg Ewing
mailto:greg.ewing@canterbury.ac.nz> wrote: No, it would be done by checking type slots, no MRO search involved.
Can you elaborate on this for my understanding?
For frequently-used special methods such as __getitem__, the type object contains direct pointers to C functions (so-called "type slots"). These are set up when the type object is created (and updated if the MRO is modified). For classes written in Python, they are filled with wrappers that invoke the user's Python code. So the implementation of the bytecodes that perform indexing would first look for a value in the slot for __getindex__; if it finds one, it calls it like a normal function. Otherwise it does the same as now with the slot for __getitem__. The overhead for this would be just one extra C pointer check, which you would be hard-pressed to measure.
the index operator recognizes this as a tuple:
1,
But function calls do not.
We could probably cope with that by generating different bytecode when there is a single argument with a trailing comma, so that a runtime decision can be made as to whether to tupleify it. However, I'm not sure whether it's necessary to go that far. The important thing isn't to make the indexing syntax exactly match function call syntax, it's to pass multiple indexes as positional arguments to __getindex__. So I'd be fine with having to write a[(1,)] to get a one-element tuple in both the old and new cases. It might actually be better that way, because having trailing commas mean different things depending on the type of object being indexed could be quite confusing. -- Greg