[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