Hacker News Reader

Comment by shazow | Hacker News Reader

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.

View on HN

IMHO, 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.

Agreed 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)

if Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing'

Can 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?

> 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?

Less 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.

Even 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.

No, I don't find it confusing. But I read craigyk as mostly talking about the special decorator syntax, not function decoration in general.

Reply on news.ycombinator.com