[Python-3000] a slight change to __[get|set|del]item__

tomer filiba tomerfiliba at gmail.com
Sat May 27 15:15:32 CEST 2006


it's a minor issue, but i thought i should bring it up anyway:

today, __getitem__ et al take a single argument. inside the indexer,
however,
multiple items may be passed. if only one argument is passed, it is passed
as-is to __getitem__; however, when multiple arguments are passed, a tuple
is passed to __getitem__. for example:

>>> class x(object):
...     def __getitem__(self, index):
...         print index
...
>>> y = x()
>>> y[1]
1
>>> y[1,2]
(1, 2)

which makes it impossible to diffrenciate between
>>> y[1, 2]
(1, 2)

and
>>> y[(1, 2)]
(1, 2)

etc.

i'd suggest to change __getitem__'s signature to __getitem__(self,
*indexes),
but this causes a problem with __setitem__(self, *indexes, value)... so in
order
to make it uniform, why not always pass a tuple? even in the case of a
single
argument.

i.e.,
>>> y[1]
(1,)
>>> y[1,2]
(1, 2)
>>> y[(1,2)]
((1, 2),)

i.e., __getitem__(self, indexes), where `indexes` is like a tuple of
everything that
was passed in the brackets.

functions that expect only one index, would be defined
def __getitem__(self, (index,)):
    ....

and you even get the bonus of simplifying (and slightly optimizing) the code
of the
bytecode-engine that calls __getitem__ -- it just passes the tuple without
second
thoughts.

think it's worth it? i find it more explicit, as today it's not clear
whether you
pass [(1,2)] or [1,2]. it's a subtle corner, but i'd suggest cleaning it up
as well.


-tomer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060527/d03922af/attachment.html 


More information about the Python-3000 mailing list