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


Relevant Pages

  • Re: while c =
    ... The problem with interpreting empty as false is that empty ... > If Python is too "wild" for your taste, ... In that case you wouldn't return an empty sequence if you wanted ... a false value in a sequence context but would throw an exception. ...
  • Ply(LALR) and Yacc behaving differently
    ... I am trying to implement a small compiler in python and, ... Perhaps this belongs on some compiler list, but I couldn't decide if it ... Empty ... def p_Block: ...
  • Re: How is the logical processing being done for strings like Dog and Cat
    ... All Python objects have a boolean context. ... Python's boolean operators are short-circuit operators. ... As a general rule, false values are empty: ...
  • Re: Time we switched to unicode? (was Explanation of this Python language feature?)
    ... If had been an empty set, ... the same people that are defending the current choice now. ... Python didn't even have sets until 2.3, ... Python is, in a very real sense, built on dicts, not sets. ...
  • MailingLogger 3.3.0 Released!
    ... I'm pleased to announce a new release of Mailinglogger. ... Mailinglogger provides two handlers for the standard python ... logging framework that enable log entries to be emailed either as the ... The latest releases of ZConfig, in particular, provide a great way to configure the python logging framework without having to resort to the appalling .ini-based configuration stuff: ...