3 ms·
Abstracting Control Flow
- stonemetal 13y agoWell 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 13y ago[deleted]
- Ygor 13y agoSICP 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#%_sec_2.2.3 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."
- arnarbi 13y agoThere's a parameter order bug in calls (or the definition) of retry.
- Suor 13y agoActually not, @decorator removes first argument for its sole use - http://funcy.readthedocs.org/en/latest/decorators.html http://funcy.readthedocs.org/en/latest/decorators.html
- anandabits 13y agoAbstracting 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)
- tomlu 13y agoI could comprehend the first piece of code in about 20 seconds and the final result in a couple minutes. It's pulled apart nicely, but it's not as simple any more. The end result might look better in something like Lisp or Ruby, but I don't think it's a great tradeoff in Python.
- Suor 13y agoThere 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.
- hcarvalhoalves 13y agoIt 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.
- abecedarius 13y agoHere'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/retrying.py https://github.com/darius/sketchbook/blob/master/misc/retryi... A couple things look wrong in the OP's last snippet: shouldn't ignore_small = ignore(ImageTooSmall) be ignore_small = lambda call: ignore(call, ImageTooSmall) and similarly for the definition of http_retry?
- Suor 13y agoNo, @decorator takes care of it - http://funcy.readthedocs.org/en/latest/decorators.html http://funcy.readthedocs.org/en/latest/decorators.html
- abecedarius 13y agoOK, 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.
- Suor 13y agoOh, I probably should spend some time clarifying the docs. But basically it just helps avoiding nesting functions, a common boilerplate when writing decorators.