On Thu, Oct 13, 2011 at 7:02 PM, Aaron DeVore <aaron.devore@gmail.com> wrote:
A clean way to have multiple function could be an issue. Perhaps add a syntax to refer to either the first function (@) or a named function(@x)? I can't think of a great syntax to group the function definitions, though.
One of the key things I realised after reflecting on both Ruby's blocks and Python's own property descriptor is that it's *OK* to only support a single function in this construct. There's a wide range of common use cases where the ability to provide a full capability one shot function would be quite helpful, especially when it comes to callback based programming. Even in threaded programming, giving each thread it's own copy of a function may be a convenient alternative to using synchronisation locks. Actually, here's an interesting example based on quickly firing up a worker thread: postdef t = threading.Thread(target=def); t.start() def pointless(): """A pointless worker thread that does nothing except serve as an example""" print("Starting") time.sleep(3) print("Ending")
1. Leave classes out of it, at least for now. We did that with decorators, and I think it's a reasonable approach to follow.
-1. This sounds useful for classes. I'm not sure what, but it still sounds useful.
We need more than that to justify keeping classes in the mix - if we can't think of clear and compelling use cases, then it's better to omit the feature for now and see if we really want to include it later.
2. The initial version should be an alternative to decorator syntax, not an addition to it. That is, you wouldn't be able to mix the first incarnation of a block prefix with ordinary decorators.
That would kill off usage of some handy decorators like functools.wraps:
:some_func(@) @wraps(other_func) def f(b): # function body
No it wouldn't, they'd just need to be called explicitly: postdef some_func(wraps(other_func)(def)) def f(b): # function body As with classes, I'm tempted to call "YAGNI" (You Ain't Gonna Need It) on this aspect of the initial specification. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia