George Sakkis <[EMAIL PROTECTED]> writes: > For example, consider the container methods __len__, __iter__ and > __contains__. The obvious choice for a null container is an empty > one. When taking __getitem__ into account though, the behaviour > looks inconsistent: > >>> Null[3] > Null > >>> len(Null) > 0
I think the typical use case of Null (a special object designed to allow any use harmlessly) would allow the above inconsistency as the least-worst solution. > Another group of methods is rich comparisons: Should Null > x be > allowed and if so, what it should return ? I expect this should take advantage of the following provision from <URL:http://docs.python.org/ref/customization.html>: A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments. … So, perhaps 'Null.__cmp__' should always return 'NotImplemented', allowing Python's fallback comparison behaviour to take over. -- \ "Are you pondering what I'm pondering, Pinky?" "Sure, Brain, | `\ but how are we going to find chaps our size?" -- _Pinky and | _o__) The Brain_ | Ben Finney w -- http://mail.python.org/mailman/listinfo/python-list
