[Python-Dev] Re: PEP 336, "Make None Callable", by Andrew McClelland
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 <anthony@interlink.com.au> It's never too late to have a happy childhood.
[Anthony Baxter]
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:
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 Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
Carlos Ribeiro wrote:
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:
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. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268
[Anthony Baxter]
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:
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 Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
Carlos Ribeiro wrote:
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:
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. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268
participants (5)
-
"Martin v. Löwis" -
Anthony Baxter -
Carlos Ribeiro -
Nick Coghlan -
Tim Peters