3 ms·
It varies. When I was helping @limedaring learn Python, I'd read source with her and explain what it does. Quite often I'd feel somewhat embarrassed when expla
by shazow 15y ago
It varies.
When I was helping @limedaring learn Python, I'd read source with her and explain what it does. Quite often I'd feel somewhat embarrassed when explaining what a line does by verbatim reading what it says.
"for user in users: ..."
"if user.is_admin: ..."
It was especially nice that the topic of "what code block does this condition apply to?" did not even occur to either of us. The indentation-based blocks made it completely organic. (Try explaining Bash to someone and when to use do/done, if/else/fi, case/esac.)
But sure, things get weird with decorators and generators and other advanced features.
- loxs 15y agoIMHO, decorators, although very useful are a big departure away from python's "simplicity" in syntax. I remember having lots of headaches several years ago wile trying to fit it in my brain. Even after I realized it is something as simple as JavaScript's myfun(fun(){}), my brain somehow continued denying to absorb it.
- dcosson 15y agoAgreed that they can be tricky initially and hard to debug, but I think they're totally worth it for eliminating repetitive code. And IMO as long as there isn't a bug in the decorator itself, code with decorators can be just as readable (if not more so) to someone else (e.g. decorating your functions with @authenticated instead of if self.user.is_authenticated: # blah, blah blah)
- craigyk 15y agoif Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing'
- j-kidd 15y agoCan you elaborate on that? The more I use Python, the more I find it to be a well thought out language with a very consistent feel, allowing me to write code without thinking. Well, except when it comes to decorators. How would you propose to improve the syntax?
- irahul 15y ago> if Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing' Better function syntax? What's wrong with python's function syntax and how does it relate to decorators? Python does have anonymous functions, though they are limited: You can have only 1 expression, you can't have statements, and you can't have local variables. The reasoning is lambdas should be used for small operations; for everything else, named functions should be used. The reasoning behind lambdas is arguable, but it still doesn't explain how it affects decorators. Consider: def memoize(fn): from functools import wraps @wraps(fn) def memoized_fn(*args): if not memoized_fn.cache.has_key(args): memoized_fn.cache[args] = fn(*args) return memoized_fn.cache[args] memoized_fn.cache = {} return memoized_fn @memoize def fib(n): if n < 2: return n return fib(n-1) + fib(n-2) print fib(100) What would a better function syntax and anonymous functions do so that memoize decorator won't be a thing?
- maxerickson 15y agoLess restricted anonymous functions would allow stuff like this: fib=memoize(function...) So the @ shortcut for: def fib(): ... fib=memoize(fib) wouldn't be necessary to 'clean up' the decoration of the function.
- irahul 15y agoEven if it were possible, I would stick with @memoize def fib: pass fib = memoize(function ...) has unnecessary nesting, and @memoize is cleaner IMO. I am curious - do you find @memoize confusing? Personally for me and anyone I have talked to, @memoize is vanilla - the confusing part is the decorator itself, especially one that takes arguments; that coupled with the fact that classes(which override __call__) and functions are both used as decorators.
- maxerickson 15y agoNo, I don't find it confusing. But I read craigyk as mostly talking about the special decorator syntax, not function decoration in general.