pep 336: Make None Callable

Alex Martelli aleaxit at
Thu Nov 4 11:11:30 CET 2004

Terry Hancock <hancock at> wrote:
> > It would be more sensible to promote the addition to builtins of a 
> > predefined null function -- one somewhat equivalent to 0, [], and {}.
> Maybe, but I think it's worth asking -- what use is the traceback from
> the None object when it is called?  Does it help in QA of code?  Is

Yes: it wards against the reasonably common bug of forgetting a return
statement, for example --

def make_adder(addend):
    def adder(augend): return addend + augend

the programmer forgot a 'return adder' as the last line -- oops, no big
deal, it will be caught extremely soon, thanks to None not being

> there a common idiom that would be broken by a callable None?

None I can think of, but then, the same could be said of many possible
loosenings -- accepting, say, " 2 + '23' " and returning either '223' or
25 would break no common idioms, either... it would just make Python
less good at catching some common bugs.  Errors should not pass

"Null Object" is a great Design Pattern (not in the Gof4 book, but still
a classic, from a reasonably early PLOP), and I would love it if Python
embodied it, as it embodies so many other useful ones.  But we should
not overload None to play the role of Null, I think.  Rather, Null
should be another object, either built-in or in some module.  Besides
the equivalent of a 'def __call__(self, *a,**k): return self', it should
have many other "do-nothing" special methods -- including a __getattr__,
btw.  We should also have type(Null) is Null -- and Null should be
subclassable too, because there are a few design choices which, however
we make them in the Null class, may need tweaking in a user-coded
subclass (e.g., should str(Null) be 'Null' or ''?).

There are Null Object classes in the cookbook -- all the way from a
simple 'donuttincallable' to a full-fledged Null Object -- and that's
where I'm putting all of my considerations on the issue, but I'll be
glad to have them embodied in a PEP if needed.

But the Null should NOT be None, the DEFAULT return value of functions
without a return statement etc etc.  Explicit is better than implicit.


More information about the Python-list mailing list