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

31–35 of 35 posts

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

#31

Post by alangpierce »

untitaker_ wrote: post #28
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.…

You're right, I hadn't seen blueprints, and they do seem to address my concerns pretty nicely.

All of the examples that I've seen (including the Flask quickstart guide, the linked post, and everything I could find on http://flask.pocoo.org/community/poweredby/ ) work by assigning the Flask app to a module-level variable (i.e. a global), then using that global at import time for all @app.route usages, so my assumption has been that that's the encouraged style. It at least seems to be pretty common. But I guess none of those examples are very big (only a few split the request handlers across multiple files), so they didn't get to a point where blueprints would be especially useful.

(Also, to be clear, when I say "imports shouldn't have side-effects", what I mean is that top-level code (which runs at import time) should ideally have no side effects.)

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

#32

Post by sfilipov »

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…

The @ syntax is just syntactic sugar.

  @decorator
  def function():
      print("Hello World!")
is equivalent to:

  def function():
      print("Hello World!")
  function = decorator(function)

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

#33

Post by geofft »

sfilipov wrote: post #32
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…

The @ syntax is just syntactic sugar. @decorator def function(): print("Hello World!") is equivalent to: def function(): print("Hello World!") function = decorator(function)

Exactly. In particular, the decorator can be an expression, so

  @decorator_factory(foo, bar)
  def function():
      print("Hello World!")
becomes

  def function():
      print("Hello World!")
  function = decorator_factory(foo, bar)(function)
or in this case, app.route(path)(function). So route() needs to return something that can be called with one argument. That's executed immediately at the time the function is defined.

Also the syntactic sugar lets you do stupid things like

  >>> @print
  ... def f():
  ...   pass
  ... 
  
  >>> repr(f)
  'None'
because print is a function that has a side effect and returns None. (If you're on Python 2, don't forget to `from __future__ import print_function`)

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

#34

Post by level09 »

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?

The short answer is, faster development, easier to maintain and extend, and even more efficiency which is exactly what I was looking for.

the long answer is, a combination of many things: - flask is simpler, has almost no learning curve

- Django's ORM is not great, and I preferred nosql where things can be done faster and no schema migration was needed

- Jinja2 seemed better and the template structure was simpler, and the static file serving seemed more straight forward in flask

- settings management, urls and routing (with decorators), blueprints and many other things ..

I really believe that Flask represents the best way to design any web framework.

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

#35

Post by rev_bird »

geofft wrote: post #4
rev_bird wrote: post #3

That. Things _that_ aren't magic. On a more relevant note, thanks for sharing this. It's always nice to read an explanation from somebody patient enough to not skip over a bunch of steps in the middle and avoid losing newbs like me.

"That" and "which" are apparently interchangeable on the other side of the pond, and the author is from Imperial College London. On a more relevant note, I agree, this is a great article. :) (I'd already known in theory how decorators work, but this was a very clear presentation, and I hadn't quite thought through the part about only needing a reference to the unmodified function, so it was useful to see that trick s…

Huh. And now I've learned about British that/which! Thank you.
Post reply on HN