> Instinctively, I agree with Tomer on this issue. But I'm reasonably > relaxed about the matter as long as it's optional. What I'm not sure > about, is if that is the intention. For example, > > class MyMap: > def __getitem__(self, key): ... > def __setitem__(self, key, value): ... > > If I pass this into a function (written by a 3rd party, so I have no > way of changing it) that *only* uses the syntax m[k] on it (never > needs to do len(m), or m.keys() or anything else), will it work? > Please note that MyMap is deliberately written to *not* conform to any > of your proposed base classes.
Paul, So long as the third-party function *only* uses m[k] on it (and m[k] is implemented through __getitem__, as it presumably would be), why wouldn't it? I'm not suggesting generic functions which do interface-based method dispatch (though we may want to do that in the future). There could be issues regarding operators, I agree. For instance, the [k] operation may be implemented by the Container interface generic implementation, in which case your type might have to have the Container interface, which currently means it would have to support __len__ and __contains__, as well. But I think that's a separable discussion, about the locality of operator implementation. Bill _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
