Null pattern

[George Sakkis]

I'd like to extend the Null pattern from
http://aspn.activestate.com/ASPN/Coo...n/Recipe/68205 to
handle special methods (e.g. Null[3], del Null['key'], Null+1) but
it's not always clear how to do it while keeping the behavior
consistent and intuitive.

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

Another group of methods is rich comparisons: Should Null x be
allowed and if so, what it should return ?

Then again, perhaps Null is an inherently domain-specific notion and
there are no general answers to such questions, in which case it
doesn't make sense trying to define an all-purpose Null object.

George

[Ben Finney]

George Sakkis <ge***********@gmail.comwrites:

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