Make 'def' and 'class' usable within expressions

[Glenn Andreas]

In article <mailman.416.1080238440.742.python-list at python.org>,
 Shane Hathaway <shane at zope.com> wrote:

> Glenn Andreas wrote:
> > What do you do if the expression is in an "if" statement?
> > 
> > 
> > if map(def(x,y,z),list1,list2,list3):
> >    # what goes here?  The body of the function
> >    # or the body of the if?  And how does the rest of it
> >    # look?
> 
> Ah, that's an interesting concern.  The same applies to "for" and 
> "while" statements.  This would have to be a syntax error.  Rewriting it 
> isn't too difficult, though, if you're willing to create an extra variable.
> 
>      condition = map(def(x,y,z),list1,list2,list3):
>          function body
>      if condition:
>          do stuff
> 
Wasn't the whole point of the use of "def in expression" to avoid having 
to use an extra variable?  After all, you currently can use an extra 
variable and get the exact same result:

   def myMapFunction(x,y,z):
      # body of function
   if map(myMapFunction,list1,list2,list3):
      # body of if

So basically, at that point, if you want to use def in expressions, for 
control expressions you'd need an extra variable, which is exactly the 
state you've got today (you just move that varible from a function to a 
value from).

> > Also, limiting to "one per expression" prevents you from doing something 
> > like:
> > 
> >    myHandlers = {
> >       "click" : def(x,y):
> >                      print "click at x,y"
> >       "enter" : def():
> >                      print "mouse entered"
> >       "exit"  : def():
> >                      print "mouse exited"
> >    }
> 
> That example reads well, although it's odd that each function can have a 
> different set of arguments.  I think you'd really want a "case" 
> statement instead, but Guido doesn't seem to want that.
> 
> Shane
> 

I was thinking more the case where you hand that dictionary to something 
like a bridge for an external UI system (in this example it might be to 
handle the various callbacks that might be bound to a button).  The 
external (native) system would just know that it has a dictionary with a 
bunch of "handlers" associated with keys.

Granted, it may be easier to hand the native UI system an object with 
specific methods which it could call (PyObject_CallMethod), but one can 
certainly imagine the system as described being used.


Personally, I like the idea of anoymous functions, and that:

   x = def(arg):
      print args+1

and

   def x(arg):
      print arg+1

are the same doesn't bother me (Lua does this exact same thing - even 
pointing out that the equivalent syntax for the latter form is nothing 
but syntactic sugar for the former (though with the word "function" 
instead of "def")).


Still, the whole thing comes down to the fact that statements are 
terminated by new-lines & use indentations, and expressions are 
(normally) within a single line (and ignore indentation when they 
aren't).  The impediance between the two is pretty high, so trying to 
mix them isn't going to be easy or pretty.