Raymond Hettinger wrote:
> Your example simply highlights the consequences of one of Python's
> most basic, original design choices (using getitem for both sequences
> and mappings). That choice is now so fundamental to the language
> that it cannot possibly change.
Hmm - just a thought ...
Since we're adding the __index__ magic method, why not have a
__getindexed__ method for sequences.
Then semantics of indexing operations would be something like:
if hasattr(obj, '__getindexed__'):
return obj.__getindexed__(val.__index__())
else:
return obj.__getitem__(val)
Similarly __setindexed__ and __delindexed__.
This would allow distinguishing between sequences and mappings in a
fairly backwards-compatible way. It would also enforce that only indexes
can be used for sequences.
The backwards-incompatibility comes in when you have a type that
implements __getindexed__, and a subclass that implements __getitem__
e.g. if `list` implemented __getindexed__ then any `list` subclass that
overrode __getitem__ would fail. However, I think we could make it 100%
backwards-compatible for the builtin sequence types if they just had
__getindexed__ delegate to __getitem__. Effectively:
class list (object):
def __getindexed__(self, index):
return self.__getitem__(index)
Tim Delaney
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4