Comment by Y7ZCQtNo39 | Hacker News Reader

Comment by Y7ZCQtNo39 | Hacker News Reader

Parent Full thread

I'm not a huge fan of decorators since they obfuscate the state of the runtime. What exactly does the call stack look like when login gets invoked? What variables are in scope? I find it difficult to reason about.

I understand that this function will execute when the HTTP server receives a GET or POST request at `/login`. The semantics of the decorator is clear-- I don't particularly take issue with that.

But the second my assumptions about the decorator break down (e.g., I think I've defined a decorator properly, but I have not), all bets are off on how to make it function properly. It's not as simple as going to the source code for the module and see what API's I'm calling.

Well, You'll be happy to know that a decorator is literally just a function that takes another function as its first argument.

    @app.route(...)
    def login():
        ...

Is literally the same thing as -

    def login():
        ...

    login = app.route(login, ...)

Hopefully that clears up the air a bit?

It clears it up but personally, I'd rather just write `app.route(login, ...)`. Isn't a lot clearer to use more conventional language features? What exactly is this buying me?

I don't know if me saying 'Just, why?' is a good enough reason to throw my arms up and say it's an idea I'm not a fan of. I'm willing to say that it's a rather subjective attitude.

I guess my retort is that, it's far more confusing to have that syntax, then explain what it meant, when I could've just used the conventional syntax.

It's not like it's offering me something substantially simpler. For example, the spread operator that was introduced. It actually allows you to write clearer JavaScript code. This syntax isn't intuitively clear like the rest operator is.

Reply on news.ycombinator.com