[Python-Dev] anonymous blocks

[Guido van Rossum]

> What was your opinion on "where" as a lambda replacement?  i.e.
> 
> foo = bar(callback1, callback2) where:
>      def callback1(x):
>          print "hello, "
>      def callback2(x):
>          print "world!"

I don't recall seeing this proposed, but I might have -- I thought of
pretty much exactly this syntax in the shower a few days ago.

Unfortunately it doesn't solve the lock-release use case that is more
pressing in my mind.

Also, if you want top-down programming (which is a fine coding
style!), we already have several ways to do that.

> I suspect that you like the define-first approach because of your tendency
> to ask questions first and read later.  That is, you want to know what
> callback1 and callback2 are before you see them passed to
> something.  However, other people seem to like to have the context first,
> then fill in the details of each callback later.

I think it all depends, not so much on the personality of the reader,
but on the specifics of the program. When callback1 and callback2 are
large chunks of code, we probably all agree that it's better to have
them out of the way, either way up or way down -- purely because of
their size they deserve to be abstracted away when we're reading on
how they are being used. A more interesting use case may be when
callback1 and callback2 are very *small* amounts of code, since that's
the main use case for lambda; there knowing what callback1 and
callback2 stand for is probably important. I have to say that as long
as it's only a few lines away I don't care much whether the detail is
above or below its application, since it will all fit on a single
screen and I can look at it all together. So then the 'where' syntax
isn't particularly attractive because it doesn't solve a problem I'm
experiencing.

> Interestingly, this syntax also works to do decoration, though it's not a
> syntax that was ever proposed for that.  e.g.:
> 
> foo = classmethod(foo) where:
>      def foo(cls,x,y,z):
>          # etc.

This requires you to write foo three times, which defeats at least
half of the purpose of decorators.

> foo = property(get_foo,set_foo) where:
>      def get_foo(self):
>          # ...
>      def set_foo(self):
>          # ...
> 
> I don't mind @decorators, of course, but maybe they wouldn't be needed here.

As I said before, I'm not sure why keeping get_foo etc. out of the
class namespace is such a big deal. In fact, I like having them there
(sometimes they can even be handy, e.g. you might be able to pass the
unbound get_foo method as a sort key).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)