chop() and empty() functions

[Jeremy L. Moles]

I've been using the following lambda/function for a number of months now
(I got the idea from someone in #python, though I don't remember who):

def chop(s, n):
"""Chops a sequence, s, into n smaller tuples."""

return zip(*[iter(s)] * n)

....or...

chop = lambda s, n: zip(*[iter(s)] * n)

I was wondering if something like this already exists in Python proper
somewhere, perhaps in an optimized way? (I checked itertools, but I
didn't see anything right away).

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
(usually defining a: empty = lambda *a, **k: None somewhere at the
topmost module space), but if enough people did too, it might be worth
adding an empty() builtin to much later versions of Python.

Anyways, if these are stupid ideas I'm not surprised. Just some things
I've been thinking about and figured I'd toss out there on my lunch
break. :)

[John Machin]

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?
(usually defining a: empty = lambda *a, **k: None somewhere at the
topmost module space), but if enough people did too, it might be worth
adding an empty() builtin to much later versions of Python.

[Paul Rubin]

John Machin <sj******@lexicon.net> writes:

What is the use case? Why write something like """empty(foo, 42,
cmd="xyzzy")""" when you could merely write "pass" or nothing at all?

The function might be a parameter to something.

[Jeremy L. Moles]

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
on.

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

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...

evhandlers[ev](*args)

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."

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).

Again, it's not a big deal. Just wondered what people thought. :)

(usually defining a: empty = lambda *a, **k: None somewhere at the
topmost module space), but if enough people did too, it might be worth
adding an empty() builtin to much later versions of Python.

[John Machin]

On 27/05/2006 6:41 AM, Paul Rubin wrote:

John Machin <sj******@lexicon.net> writes:

What is the use case? Why write something like """empty(foo, 42,
cmd="xyzzy")""" when you could merely write "pass" or nothing at all?

The function might be a parameter to something.

Please bear with me; it's only about 7 a.m. in this neck of the woods
and I've had only 2 cups of coffee so far :-)

So one is calling some functions defined like:

def something1(..., afunc, ...):
...
if afunc([], 1.23, "plugh") is None:
....

and

def something2(bfunc, ...):
...
if bfunc(sys.stdout, "teehee", 0666) is None:
....
etc etc

and there are so many xfuncs with different argument signatures and so
many times that the caller wants to supply a do-nothing xfunc that
defining a swallow-any-and-all-args empty() function is warranted???

Thanks in advance for any enlightenment,
Cheers,
John

[bearophileHUGS]

Jeremy L. Moles>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."<

There's some correlation with the Null Object pattern:
http://www.cs.oberlin.edu/~jwalker/nullObjPattern/

Bye,
bearophile

[John Machin]

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
on.

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

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...

evhandlers[ev](*args)

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

Cheers,
John