3 ms·

>Need to access the request? use `req` Well, I don't see what's especially difficult about this? from flask import request @app.route('/login', metho

by devxpy 8y ago

>Need to access the request? use `req` Well, I don't see what's especially difficult about this? from flask import request @app.route('/login', methods=['GET', 'POST']) def login(): if request.method == 'POST': return do_the_login() else: return show_the_login_form() I would actually argue that this is better, since I have to type "request" only once. Although I have to admitt, the middleware thing looks quite composable.

Y7ZCQtNo39 8y ago
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.
- devxpy 8y ago
  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?
  - Y7ZCQtNo39 8y ago
    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.
hardwaresofton 8y ago
Other people basically covered it but yeah my problem is how `request` comes out of nowhere. The NodeJS snippet is way more obvious, treating the two handlers as separate (`app.get`, `app.post`) is cleaner, and it's immediately obvious what's happening, no need to know about `flask.request` to undrestand the code. I have come to abhor non-obvious code, and on that metric the flask code loses by a step in my mind. If we really want to get in the weeds, we could talk about python 2.x's floundering around async IO -- IIRC Twisted/Tornado/Gevent/Eventlet were all close to equally good options (and thus mindshare was split) while node had it built in, with a virtualenv-by-default packaging system. Also there's WSGI -- the interoperability it provides is cool, but also means more moving parts than a simple node+express setup. I don't want to make this a nodejs vs python thing, because that's a really dumb conversation (argument) to try and have, but personally node+express is what I pick over python+flask any day of the week for spinning up simple "just-good-enough" web services. These days I've been checking out Molten and Falcon (I'm a huge fan of pypy) but when I need to build a quick server I just pick up node+typescript.

by devxpy 8y ago

Y7ZCQtNo39 8y ago

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.

devxpy 8y ago
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?
- Y7ZCQtNo39 8y ago
  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.

hardwaresofton 8y ago

Other people basically covered it but yeah my problem is how `request` comes out of nowhere. The NodeJS snippet is way more obvious, treating the two handlers as separate (`app.get`, `app.post`) is cleaner, and it's immediately obvious what's happening, no need to know about `flask.request` to undrestand the code. I have come to abhor non-obvious code, and on that metric the flask code loses by a step in my mind. If we really want to get in the weeds, we could talk about python 2.x's floundering around async IO -- IIRC Twisted/Tornado/Gevent/Eventlet were all close to equally good options (and thus mindshare was split) while node had it built in, with a virtualenv-by-default packaging system. Also there's WSGI -- the interoperability it provides is cool, but also means more moving parts than a simple node+express setup. I don't want to make this a nodejs vs python thing, because that's a really dumb conversation (argument) to try and have, but personally node+express is what I pick over python+flask any day of the week for spinning up simple "just-good-enough" web services. These days I've been checking out Molten and Falcon (I'm a huge fan of pypy) but when I need to build a quick server I just pick up node+typescript.