Hacking Flask: A Success Story
blog.sendhub.com
blog.sendhub.com
It also seems designed from the ground up to be tinkered with and modified so I'm not worried about having to monkeypatch things weirdly or that my mods will break plugins.
It's one of the few software projects I rave about!
"Read the source. Flask’s code is written to be read; it’s documentation published so you can use its internal APIs. [...] The API docs are full of available overrides, hook points, and Signals. [...] The Flask class has many methods designed for subclassing [...] You can introduce WSGI middleware to wrap your Flask instances and introduce fixes and changes at the layer between your Flask application and your HTTP server [...] If none of the above options work, fork Flask."
Even from just a software architecture perspective, I'm incredibly impressed with what Armin Ronacher has done with this project.
Does SendHub use Flask in any sort of production environment? It's always been touted as a great small framework, but rarely (if ever) do we hear about sites using it in some sort of large-scale effort.
With regard to large-scale projects, the usage at SendHub is substantial. I am also aware of flask-restful[1], which looks like it could be useful for building out a more complex API service.
To be completely honest with you, I would gladly take Flask over Django/TastyPie or any of the other numerous Python frameworks I've worked with. For me it brings back the pleasure to coding in Python -- even if this is a case of redefining methods because Flask and Werkzeug are such thin layers that there is simply no configuration! There is certainly nothing comparable to the awesome power of Jetty on the JVM in Python.
Could you explain the benefits or difference for you?
Personally, I enjoyed using Tastypie, and when things weren't clear, its code was a pleasure to read and made things easier to understand or work out how to solve. Perhaps similar to your experience with the Flask code.
I imagine a thinner framework is cleaner in many ways, but then with a more robust framework you get stuff out of the box. In this particular case, getting the request time (+ if you want, sql time etc) is relatively easy and there are a few middleware options to do it in Django.
I've seen an interesting talk[1] by Yehuda Katz: "why rails is hard". One of the key points, if I can somehow paraphrase, is that with a bigger framework like rails, you get a lot more out of the box for the 'price' of it being heavier... He's comparing rails to node and sinatra, but the same might apply to the comparison between django/tastypie and flask I suppose.
Finally, I don't know about flask, but another important point in Yehuda's talk was that some of those things implemented for you, you might not even know that you need. This is true particularly for security, where you probably don't have to think about whether XSS/CSRF protection is implemented etc, you just want things to be secure by default and it's not a feature you even think about...
I am not saying flask doesn't have those (I don't know), just that in general that's usually the trade-off between heavier and lighter frameworks. (I think) I know the downsides, I'm curious to know about the upsides too.
http://pythonhosted.org/Flask-WTF/
This page outlines some further security considerations:
Do you talk over HTTP to backend services, encoding it via JSON?
[2] I didn't understand what you mean't about Jetty here (I like its philosophy too :)
#2: Jetty provides tons of configuration options, whereas Flask has very little in the way of configuration other than swapping out components.
The better and more general approach would be using a WSGI middleware.
super(MyFancyRequestHandler, self).send_response(code, message=message)
instead of: super(MyFancyRequestHandler, self).send_response(code, message=None)
(or even better, with args and kwargs)? Otherwise it seems that the message is discarded and None is always passed. This is one of the places where python's syntax is awful IMHO. Setting a default value shouldn't be the same as passing a parameter. super(ClassYouObviouslyMean, self).send_response(*a, **kw)
super().send_response(*a, **kw)
Spot the python3 syntax: def f(x=default_value, y=None): pass
def f(x:arbitrary_object=default_value,
y:this_doesnt_equal_None_y_does=None) -> more_wtf: ...I've been playing around with Bottle, largely because I want a python 3 web framework, but I would much rather build with Flask.
https://twitter.com/mitsuhiko/status/323177177367601152
looks like Armin is gearing up to take care of business!
I'm trying learn Tornado and every time I'm caught thinking: If only their docs were like pocoo..
Many python projects have PDF docs produced automatically by readthedocs, although they're often not easily discoverable.
The big difference is that Flask is based on other technologies such as Werkzeug and Jinja2 that exist for a longer time and it does not try to reinvent things. Bottle on the other hand tries to stick to the one-file approach. I want to merge them but the Bottle developer does not seem to be very happy about the idea of stepping away from the “one file” requirement.
Regarding flexibility: there are no reasons you shouldn't be able to use flask with other template engines if that's what you're after. In fact, things like Flask-Genshi exist: Flask-Genshi and it's incredible easy to use mako with it, even without extension if you want to.
Bias warning: I am the developer of Flask, Werkzeug and Jinja2.
http://stackoverflow.com/questions/4941145/python-flask-vs-b...
In my own experience, both are great, and similar. For a simple REST API bottle has an added advantage of being a single file which is nice to just include with all of your other code rather than having to install anything. Flask, however, is my go-to framework. I used it extensively at a previous job and still do today with my current employer (and the app is pretty substantial). Flask also has a lot of extension support now. A pip freeze | grep Flask yields the following for one project.
Flask==0.9
Flask-Admin==1.0.5
Flask-Assets==0.8
Flask-Babel==0.8
Flask-Cache==0.10.1
Flask-Classy==0.5.2
Flask-DebugToolbar==0.7.1
Flask-Gravatar==0.3.0
Flask-Login==0.1.3
Flask-Principal==0.3.4
Flask-SQLAlchemy==0.16
Flask-WTF==0.8.2And seeing that Flask still does not support Python 3, while Bottle does, I'm happy with the decision of the Bottle developer.
Not to mention that the "one file" makes deployment very easy.
Plus: Bottle is quite faster than Flask, even if you count the overhead of a DB query:
http://blog.curiasolutions.com/the-great-web-framework-shoot...
If you see bottle being faster than Flask in a real-world benchmark and the difference the problem there are still knobs to turn if you need to. Flask does not optimize at all for Benchmarks and you pay for some overhead out of the box for a better development experience.
(bottle user here too)
Also, Flask the concept of modules/Blueprints for building larger apps. I'm not sure whether Bottle does or not, but the bottle website seems to imply that it's optimized for single file applications.
I used Bottle for a small learning project, though, and found conceptually a lot of things are very similar. We ended up using Flask because it seemed better constructs were in to use it as a foundation for a large code-base, similar to Django, but custom built with legos.
Edit: removed markdown urls
The good news is that the original meaning of the term hacking/hacker/to hack seems to have regained popularity in recent years.
You probably weren't the only person to think what you did but by reclaiming what is truly ours we can win. Note also that you are reading a site called 'hacker' news.
Personally I make it a rule never to use the term 'hacker' in the media coopted sense.