Home Original page

pep 336: Make None Callable

Mike C. Fletcher mcfletch at rogers.com
Thu Nov 4 02:18:32 EST 2004 
Bengt Richter wrote:

>On Wed, 03 Nov 2004 20:59:43 -0700, The Eternal Squire <eternalsquire at comcast.net> wrote:
>  
>
...

>>Abstract
>>
>>    None should be a callable object that when called with any
>>    arguments has no side effect and returns None.
>>    
>>
...

>IMO in the context of selectable actions, the noop should be a noop function,
>not None, e.g.,
>
>    def Noop(*args, **kwargs): pass
>  
>
IMO this (defining an object (e.g. a function)) which is explicitly 
intended to be used for such a thing is far better than adding to the 
semantics of None at this late date.  For instance, the original 
proposal would completely change the semantics of this code:

    method = methods.get( someKey )
    try:
        method( my, arguments, are=here)
    except TypeError, err:
        pass

it would also alter the results of this:

    callable( None )

so that any code which is using the exception-raising or callable to 
catch an undefined method-table-lookup will now fail (silently, I might 
add).

Defining a function/object for use in such situations is fine, but 
altering such commonly referenced functionality of one of the most 
"core" objects in Python is, I would suggest, a seriously sub-optimal 
forward path.  The path forward, I would think, would be to find a good 
place for such a function/object to live and slotting it in there so 
that it's naturally available.  If there were, for instance, a 
"functional" module, with such an object in it, it would make perfect 
sense to write:

    methods.get( somekey, functional.noop )

and you would get the functionality without muddying the semantics of 
None at this late date.

Just MHO,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com
More information about the Python-list mailing list