Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things which aren't magic – Flask and app.route

ains.co

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Things which aren't magic – Flask and app.route

#21

Post by ddorian43 »

manto wrote: post #16
level09 wrote: post #12

Flask is incredible. since I've made the transition from PHP-based CMS's I've never looked back. if someone is interested in learning more about building larger scale/production apps with flask, I have a series of tutorials at medium to get you started: https://medium.com/@level09 Disclaimer: I'm the creator of enferno ( http://enferno.io ), A flask-based system pre-configured with caching/user auth/basic template/OR…

Curious what made you go this route rather than say a more full featured framework (Django/Rails)? Just based on assumptions, was it the ability to specify each of your preferred components?

For me because jinja2 is better than django's templates, sqlalchemy is also better than django orm. And you can use them as separate (sqlalchemy on desktop app), blueprints also (for me at least), everything is not tied to the sql-orm so you can use nosql to webscale.

Re: Things which aren't magic – Flask and app.route

#22

Post by ekimekim »

zrail wrote: post #6
josefdlange wrote: post #5

What's throwing me off -- and I'm sure it's something trivial I'm not seeing -- is how we add the functions to the routes dictionary. When is the decorator's code actually executed? Is that done at import time? My assumption is that its code is executed when its counterpart is called, though clearly that mustn't be the case. Given my understanding from the article, there's a hole: how does serving route "/" know to c…

Plain decorators work how you expect but generators are different. The decorator generator is called at import time, which is when the association between the route and the function is stored.

Well, no. The decorator generator is called first, then the decorator is called, all at the time when the line "@app.route()" is first reached during import. You could just as easily write @foo.bar[baz]('abc').hello and it would still work - the code after the @ is just an expression that should return a callable.

Re: Things which aren't magic – Flask and app.route

#23

Post by Nullabillity »

alangpierce wrote: post #15

Flask's route decorator gives a nice syntax, but it goes against some ideal best practices: * Imports shouldn't have side-effects (like registering functions with flask). * You shouldn't use globals (like the flask app). * Objects (such as the flask app) should be immutable whenever possible. None of these are hard-and-fast rules, and Python code has a tendency to give up purity in favor of syntax, so it's certainly…

Check out blueprints[1], they pretty much do what you just talked about.

[1]: http://flask.pocoo.org/docs/0.10/blueprints/

Re: Things which aren't magic – Flask and app.route

#25

Post by josephlord »

josefdlange wrote: post #5

What's throwing me off -- and I'm sure it's something trivial I'm not seeing -- is how we add the functions to the routes dictionary. When is the decorator's code actually executed? Is that done at import time? My assumption is that its code is executed when its counterpart is called, though clearly that mustn't be the case. Given my understanding from the article, there's a hole: how does serving route "/" know to c…

Yes I had to think about it and test it (not done much Python recently). The decorating function is called as soon as the decorated function is declared.

These are the results of a simple test in the Python console.

  >>> def dec(f):
  ...   print "Decorator ran"
  ...   return f
  ... 
  >>> @dec
  ... def decorated(i):
  ...   print "Decorated function ran"
  ... 
  Decorator ran
  >>> decorated(5)
  Decorated function ran
  >>> decorated(5)
  Decorated function ran

Re: Things which aren't magic – Flask and app.route

#26

Post by lmm »

bigb9320 wrote: post #14

Am I right in understanding that decorators are a form of closures as the decorator function is returning the function declared inside it ?

Only in a trivial syntactic sense. They're better understood (IMO) as combinators, though even that isn't absolutely accurate.

Of course ultimately a word can mean different things; did you have a more specific question about what a decorator or a closure does?

Re: Things which aren't magic – Flask and app.route

#28

Post by untitaker_ »

alangpierce wrote: post #15

Flask's route decorator gives a nice syntax, but it goes against some ideal best practices: * Imports shouldn't have side-effects (like registering functions with flask). * You shouldn't use globals (like the flask app). * Objects (such as the flask app) should be immutable whenever possible. None of these are hard-and-fast rules, and Python code has a tendency to give up purity in favor of syntax, so it's certainly…

>Imports shouldn't have side-effects (like registering functions with flask).

Imports don't have side-effects. Using Flask's route decorators has.

>You shouldn't use globals (like the flask app).

The Flask app is just as much a global as any other class instance in any OOP language. Whether you make it a module-level object or not is your choice.

>Objects (such as the flask app) should be immutable whenever possible.

They hardly are. This is a good rule which nobody follows, and I don't think you'd gain enough advantages through this.

>You need to make sure that you import every file with a request handler, and those imports often end up unused (only imported for their side-effects), which confuses linters and other static analysis tools.

The fact that your app has import side-effects is your fault, this pattern is not at all encouraged by Flask. You probably want to use blueprints.

Re: Things which aren't magic – Flask and app.route

#30

Post by ainsej »

untitaker_ wrote: post #27

The term decorator generator is incredibly misleading, as it implies relation to Python generators . The term decorator factory (or just decorator with parameters ) is preferrable.

Author here, and good point! I was struggling a bit with the terminology to use, didn't think of decorator factory, it definitely would have been a bit clearer.
Post reply on HN