annonymous functions -- how to

[Dave Benjamin]

Fredrik Lundh wrote:
> Dave Benjamin wrote:
> 
>>>so name them all "func" or "next" or something, so you don't have
>>>to think.  once the object is bound, the name is irrlevant.
>>
>>Sure, you could do this, but then you'd have multiple functions at
>>different nesting levels with the same name, which would be confusing.
> 
> "I don't wanna try that", you mean.

No, I mean, "I have an imagination". But for the sake of argument, here, 
I'll try that:

def add_thingy():
     def func(thingy_id):
         print 'got thingy id:', thingy_id
         def funnc(doodad_id):
             print 'got doodad id:', doodad_id
             def func(thingy_doodad):
                 print 'thingy doodad created, froobling...'
                 frooble(thingy_doodad)
                 print 'froobling complete'
             with_new_thingy_doodad(thingy_id, doodad_id, func)
         with_next_doodad_id(func)
     with_next_thingy_id(func)

This function now has an infinite loop. Can you spot the reason?

> because if you had done so, you would have noticed that "multiple
> functions with the same name" doesn't have to be any more confusing
> than "multiple print statements" or "multiple if statements" (as long as
> you're not using bad names on purpose, of course).

I have noticed. It is more confusing. That's the whole point.

>>>there's also:
>>>
>>>    def add_thingy(self):
>>
>>What object is "self"? Are we defining a method at this point?
> 
> if you have a problem with methods, you shouldn't use Python.

No, I was asking you to clarify, are we rewriting "add_thingy" to be a 
method, and if so, what class is it a method of, and what are its 
responsibilities? Because it seems like this example now shares data 
through an instance, but this data is not required for any other method, 
so it will add clutter to the instance namespace. If anything, it seems 
that "add_thingy" should be moved into another class at this point, in 
which case it follows that every method that needs to do this sort of 
asynchronous communication would likewise be moved to a new class. This 
is fine, I suppose, but it's a lot more verbose.

>>>        yield get_new_thingy_id; thingy_id = self.result
>>
>>What is "get_new_thingy_id"? A function? To whom are we yielding here?
> 
> I could have sworn that you mentioned event-driven programming
> in your original post.  if that's still what you're doing, the answers
> are "a token" and "the event source".

I am just trying to make sense of your example. I am still talking about 
event-programming. Here are the events:

1. Program A sends program B a message, saying, "I need a thingy ID".
2. B sends A a message, "Here's a thingy ID: 42".
3. A sends B a message, "I need a doodad ID".
4. B sends A a message, "Here's a doodad ID: 43".
5. A sends B a message, "Make a thingy doodad with IDs 42 and 43".
6. B sends A a message, "Thingy doodad created".
7. A sends B a message, "Now, frooble the thingy doodad".

I don't know what parts of this transcript you would consider "tokens". 
And I'm also not sure how generators can provide an alternative solution 
to this problem. I am genuinely interested.

Dave