Abstracting Control Flow(hackflow.com)
hackflow.com
Abstracting Control Flow
http://hackflow.com/blog/2013/10/08/abstracting-control-flow/
6 comments
There is a price for new vocabulary involved, which is some learning curve.
By the way, first piece of code can become much more hairy with time.
By the way, first piece of code can become much more hairy with time.
It depends on what you consider simple. I don't consider the earlier code simple, just crude. Testing it, or adding features (e.g., tacking caching) would increasingly make it messier, plus the code mixes error handling and low-level concerns with business logic.
The final result is broke up in nicely referentially transparent functions, making testing or refactoring more trivial. Also, the main body reads as a DSL, a programmer can pick this code and more easily figure out what it does, which is easier to reason about.
The final result is broke up in nicely referentially transparent functions, making testing or refactoring more trivial. Also, the main body reads as a DSL, a programmer can pick this code and more easily figure out what it does, which is easier to reason about.
SICP has a great chapter with an example of how to modularize an entangled code:
Chapter 2.2.3: Sequences as Conventional Interfaces,
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-15.html...
"The value of expressing programs as sequence operations is that this helps us make program designs that are modular, that is, designs that are constructed by combining relatively independent pieces."
Chapter 2.2.3: Sequences as Conventional Interfaces,
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-15.html...
"The value of expressing programs as sequence operations is that this helps us make program designs that are modular, that is, designs that are constructed by combining relatively independent pieces."
Abstracting control flow is extremely powerful. Those interested in learning more should explore monads, which offer some very useful methods of generalizing and composing control flow abstractions.
http://en.wikipedia.org/wiki/Monad_(functional_programming)
http://en.wikipedia.org/wiki/Monad_(functional_programming)
Here's another retry abstraction that in some ways is more general (decide whether to keep trying some other way, or sleep a bit before the next try, etc.): https://github.com/darius/sketchbook/blob/master/misc/retryi...
A couple things look wrong in the OP's last snippet: shouldn't
A couple things look wrong in the OP's last snippet: shouldn't
ignore_small = ignore(ImageTooSmall)
ignore_small = lambda call: ignore(call, ImageTooSmall)
No, @decorator takes care of it - http://funcy.readthedocs.org/en/latest/decorators.html
OK, cool. Some feedback: I still don't understand what your @decorator does, after looking over that page, then finding the source code and finding it to call other functions with no doc comments, which call other functions with no doc comments, etc.; after about 3 levels I gave up, not interested enough. This on top of the blog post including it with no explanation.
I've seen a @decorator function defined by Peter Norvig before, but it only propagated metadata, it didn't change the usual functionality of its argument.
I've seen a @decorator function defined by Peter Norvig before, but it only propagated metadata, it didn't change the usual functionality of its argument.
Oh, I probably should spend some time clarifying the docs.
But basically it just helps avoiding nesting functions, a common boilerplate when writing decorators.
But basically it just helps avoiding nesting functions, a common boilerplate when writing decorators.
Well written article. I think this is the first time I have seen aspect oriented programming explained in such a way that I found the concept compelling.
[deleted]
The end result might look better in something like Lisp or Ruby, but I don't think it's a great tradeoff in Python.