Abstract
None should be a callable object that when called with any arguments has no side effect and returns None.
My response to this is simply "yuck". This is a hack, abd I don't think it's worthwhile. If you want to test for None, test for None. Similarly, if you want a dictionary lookup to default to a no-op method, there's a perfectly simple way to spell it now:
def defaultNoopMethod(*args, **kwargs): pass somedict.get(key, defaultNoopMethod)
You can even do this as a one-liner using a lambda if you want.
Anthony
[Anthony Baxter]
Abstract
None should be a callable object that when called with any arguments has no side effect and returns None.
My response to this is simply "yuck". This is a hack, abd I don't think it's worthwhile.
Maybe it's not a coincidence that it's listed in the PEP index next to "Reject Foolish Indentation" <0.9 wink>.
IMO, it's worse than not worthwhile: it would be actively bad to implement this.
TypeError: 'NoneType' object is not callable
is a frequent runtime occurrence now, and performs a valuable service when it happens by correctly pointing out a programming error. Python's None isn't meant to be neutral -- it's meant to mean "nothing is there", and supplying nothing where something is required is a logic error.
On Thu, 04 Nov 2004 14:13:33 +1100, Anthony Baxter anthony@interlink.com.au wrote:
Abstract
None should be a callable object that when called with any arguments has no side effect and returns None.My response to this is simply "yuck". This is a hack, abd I don't think it's worthwhile. If you want to test for None, test for None. Similarly, if you want a dictionary lookup to default to a no-op method, there's a perfectly simple way to spell it now:
def defaultNoopMethod(*args, **kwargs): pass somedict.get(key, defaultNoopMethod)You can even do this as a one-liner using a lambda if you want.
Just a question, and I sincerely hope it's not a dumb one. Python already have a noop statement ("pass"). Now, what is being requested is a standard noop callable. Does it make sense -- both in theorethical and practical terms -- to allow a statement such as "pass" to be used in both situations? In other words, does it make sense to have a "unification" of sorts?
Thanks for any pointers,
Carlos Ribeiro wrote:
Just a question, and I sincerely hope it's not a dumb one. Python already have a noop statement ("pass"). Now, what is being requested is a standard noop callable. Does it make sense -- both in theorethical and practical terms -- to allow a statement such as "pass" to be used in both situations? In other words, does it make sense to have a "unification" of sorts?
No. Theoretically, the "pass" statement exists for purely syntactical purposes: namely, to put a statement where a statement is required, but no meaningful statement can be found. As a result, "pass" has no run-time semantics: it is not the case that it is executed and does nothing, instead, it is simply not executed. The proposed "function with no effect" would be quite different: it would have a run-time semantics, which would be to ignore all arguments, and return None.
Practically, it would be very confusing if the keyword "pass" suddenly started to denote a function. Traditionally, keywords have never denoted expressions. It might be that True, False, and None become keywords some day, but these would *only* be use as expressions. It is unpythonic to give an expression meaning to a statement (just as assignment is not an expression, either).
The simplest solution to achieve the rationale of the PEP would be to add a function operator.nop. Of course, writing
def nop(*args):pass
isn't that more difficult than writing
from operator import nop
Regards, Martin
Martin v. Löwis wrote:
The simplest solution to achieve the rationale of the PEP would be to add a function operator.nop. Of course, writing
def nop(*args):pass
isn't that more difficult than writing
from operator import nop
Although the def version above has problems with keyword arguments. Still, I'd be +0 on
def nop(*args, **kwds): pass
in the operator module, in the spirit of TOOWTDI.
And I meant to add a resounding 'Aye!' to Tim's comment about the debugging value of None not being callable - that's an obvious indicator of 'I screwed up', whereas silently returning None as proposed in the PEP may trigger the error report an arbitrary distance from the original mistake.
Cheers, Nick.
-
"Martin v. Löwis" -
Anthony Baxter -
Carlos Ribeiro -
Nick Coghlan -
Tim Peters