Re: chop() and empty() functions

On 27/05/2006 7:10 AM, Jeremy L. Moles wrote:
On Sat, 2006-05-27 at 06:22 +1000, John Machin wrote:
On 27/05/2006 2:54 AM, Jeremy L. Moles wrote:

["chop" snipped]

Furthermore, what do people think about the idea of adding a truly
empty, no-op global lambda somewhere in Python? I use them a lot
What is the use case? Why write something like """empty(foo, 42, cmd="xyzzy")""" when you could merely write "pass" or nothing at all?

Well, in a lot of the libraries I use, there is often a need for a
callback of some sort. Sure, I--and most other people--often define an
empty, no-op function of some sort when you want to at least have
"something" there, but I thought it might be kinda' neat to be able to
have a builtin called empty() or noop() that returned a (possibly
optimized?) function that just did nothing. :) It probably is a dumb
idea, hehe... the chop() was the big one I thought people might comment

For example, I often do stuff like this for handling "input events" in

evhandlers = [emptyfunc for i in range(MAX_NUM_EVENTS)]

evhandlers[EVENT_NUMBER] = self.my_handler_function

...and then in the actual input loop I'll come along and say...


In this way I don't have to test the value of any event and behave
accordingly--I just send it on it's way.

It's just an iterative way to say, "Okay, give me some default behavior
for everything, and I'll come back around later and set the explicit
handlers later."

If you intend to set explicit handlers later, wouldn't it be better for the default event handler to raise an exception, just in case your intention is waylaid or sidetracked?

This same design is probably used in other areas too... that's why I
brought up the "truly empty noop" thing; it would give me fuzzy feeling
to know that in those cases where empty() is defined, nothing is
happening (although, this could currently be the case in Python, I'm not
sure--I don't know a lot about Python internals).

It would give you a fuzzy feeling to know that nothing is happening -- instead of *what* happening? What do you dread?

If, when you do evhandlers[ev](*args), evhandlers[ev] can't be evaluated to a callable object (for one of several possible reasons), Python will raise the appropriate exception. It won't "do nothing". Python will not assume that you meant to supply a no-op function. Python refuses to guess what you had in mind. This is part of the language philosophy, and is not implementat(ion|er)-dependant.

I suggest that you fire up a Python interactive prompt, and type

import this