> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
