Why so many Python web frameworks?
bitworking.org
bitworking.org
A ZeroMQ-based framework might be interesting -- Brubeck (http://brubeck.io/) is an example of this.
Nginx (https://github.com/FRiCKLE/ngx_zeromq) is starting to get support for ZeroMQ, and Mongrel2 (http://mongrel2.org/) was designed around it.
Django is great, with good re-usable components, but I like Jinja2 more than Django's templating. The argument for SQLAlchemy is more on the lines of I would prefer a standard ORM compared to everyone baking their own. SQLAlchemy used to be verbose, but the declarative extension now takes care of it.
Other things I like about flask are explicit app object, and context locals.
Yes, it is. But most of the applications are tightly coupled with Django's ORM(auth, for eg, which I use very frequently), and in the end, I end up maintaining two types of templates which I don't like.
> And second, Django's ORM isn't quite the equivalent of SQLAlchemy;
No, it isn't. But SQLAlchemy does what django's orm does, and then some.
I would prefer a compartmentalized model, where a web framework doesn't implement templating or ORM, provided a robust solution exists. The templating engine and ORM should be independent libs, and the web framework should glue them together, possibly adding a declarative layer above them(render_to_response, declarative ORM etc).
The core devs claim that SQLAlchemy and Jinja weren't around at the time Django was developed, and that's fine. But in 2012, Jinja2 and SQLAlchemy are clearly better alternatives to Django's defaults. So why not incorporate them?
Django doesn't even have first class support for Jinja2 templates, let alone the python HAML variants.
What's ironic is that a few years ago Django was known for being loosely coupled when compared to Rails, which was considered monolithic ("my way or the highway"). Nowadays Rails is the flexible framework, allowing for different ORMs and templating systems, while Django is now the monolithic framework.
Don't get me wrong, I love stability. But when a great percentage of developers are using hacks to get around the default configuration system and to support excellent external libraries like Jinja2 and SQLALchemy, something is very wrong.
There are significant limitations with some of these frameworks today, though. For example, lack of byte range/partial content support is bad news if you're serving large files (think multimedia).
We're still investigating options here, but WSGI doesn't seem ideally suited to working that way, and as far as we can tell quite a few of the "microframeworks" lack any kind of support for returning partial content automatically. The concern seems to be that WSGI would need the application to generate a complete response even if it was going to serve only part of it as a 206, because there's no standardised part of the routing set-up that says "I need these byte ranges from whatever full response you would have given me".
A common philosophy seems to be that such files should be served statically by your front-end web server anyway, but that is not sufficient in all cases. For example, you might need to process the request through your framework to generate the response on demand, implement access controls, or integrate with a custom logging/analytics framework.
[Edits: Trying to clarify key points.]
Depending on your use case, you can either use X-sendfile header - validate request, then return a X-sendfile response for your front-end server; or use gevent to stream the response.
In case it helps anyone else: It's something about the way that Flask handles a direct send_file that seems to be causing problems in our tests. However, we've found reports of sendfile not working properly on certain platforms and we're still investigating, so I'm not convinced at this stage that the problem is with Flask itself.
I am confused by your sendfile not working properly on certain platforms. If you set the X-Sendfile header, and the web server supports it, it should work fine. Flask send_file doesn't do much other than setting up the headers; and then either setting the X-Senfile header so that web server handles it, or sends it using WSGI file wrapper supports.
https://github.com/mitsuhiko/flask/blob/master/flask/helpers...
In any case, we haven't tried using the X-Sendfile functionality yet, and I'm making no comment about how well that works.
We do know, without any doubt at this point, that serving our video files using Flask's send_from_directory (using the default file wrapping behaviour, not X-Sendfile) is not working reliably for us with many different clients, where serving the same file statically straight from a web server like Apache works fine. We're still trying to identify exactly what it is that doesn't work, but in light of our discussion here today and what I've learned since then, I'm now hoping that we can just punt the whole set-up over to the known-working Apache implementation by using X-Sendfile and avoid the problem in the first place.
(Edit: Thanks again for the suggestions, BTW. I had a fairly long list of ideas to follow up in relation to this problem, including investigating X-Sendfile, but your mention of that here prompted me to look into it first and will probably have saved me quite a bit of time if it does work for us.)
http://www.python.org/dev/peps/pep-0333/#optional-platform-s...
That's environment specific; the wsgi server should define a environ['wsgi.file_wrapper'] if it needs to provide specific file handling functionality. I don't think you have an issue with Linux kernel - 2.2 and beyond will always have sendfile. It's more likely that your wsgi server isn't defining environ['wsgi.file_wrapper'] to something that uses sendfile.
If you see the flask send_file code, it's using werkzeug.wsgi.wrap_file, which in turn either uses environ['wsgi.file_wrapper'], or uses simple Python code to read the file and send the contents.
https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/w...
Reading file and sending the contents in your python code is a bad idea. You can either set debugging points and see if wsgi server is defining environ['wsgi.file_wrapper'] properly. Or more conveniently, you can just set 'USE_X_SENDFILE = True' in your flask settings, and then directly use send_file.
We used pylons for the last project, and there are areas I still don't make improvements on because it is too much effort to get into it.
Here's a more recent article in the same "DIY Python Framework" spirit, which is longer but quite good: http://docs.webob.org/en/latest/do-it-yourself.html
From the way the Python community talks about its strengths, I'd expect there to be pressure against creating a new X just because you can.
This article lends weight to the rumor.
Examples that I can think of off the top of my head are freshen/lettuce/behave, there were also a bunch of XML parsers leading into elementree (which is now in the standard library). In Ruby you have Rails, Sinatra, and a couple of other frameworks, as well as Mongrel2 and friends to run it all.
Back when this article was written there were at least five or six Python frameworks, all competing. If Django ever starts sucking, I'm sure one of them, or a completely new one, will step up to take it's place. Ditto for Rails.
All part of the open-source circle of life :)
The Python web development community is very much divided into different, although largely cooperating, groups.
Django is definitely not the default choice when it comes to web development in Python and I doubt anyone seriously involved in the Django project would ever claim that.
I would love to see a scientifically exact census but I don't think it can be done. Maybe PyPI could roughly tell the story? But you won't get a real unique-users count unless your logging identifies unique users, who wants that?
Please understand: I am not a big Django promoter, I disagree with many of its design principles, and I don't think that other things are "dead". I know that there are reasonable numbers of people out there using Zope/Plone, Flask, Pyramid, and other things. Just because Django is huge doesn't mean they are nothing or not worth looking at. I believe Rails is significantly bigger than Django, but that doesn't mean I'm switching to Rails.
But when it comes to web-framework, boy... this one is tough. I lost count on how many Python web-framework or web-library out there (feel free to debate the semantic of Flask vs Bottle vs Django vs Pylons vs Pyramid vs Plone vs Zope).
EDIT: Or rather, skimmed to the end of the article. (Like I did because I have no interest in building a python web framework and thought the title was sarcastic.)
Your comment is surprising given your expertise. Guess you are not immune to taking pot shots at Python.
If you look at the web frameworks that are available or libraries such as requests you also see why this is a very good thing.
How would that be enforced? Would someone's Python privileges be taken away?
What if the person working on xyz was inactive for a while? What if their xyz had a problem and they didn't want to fix it?
The "obvious way to do it" does not and was never, ever intended to bind anyone's hands from writing a library or app similar to something someone else wrote. It is a principle of language design, that it should give SOME consideration to readability and learnability rather than giving 100% of everything to nifty obscure features that help you write awesomely clever executable line noise.
There are a number of things no framework I have yet run into does well:
1. Unification of client side and server side events. With options like Backbone or (ugh) ExtJS on the client side, there is a lot to be gained from a coupled event subsystem over websockets, or via server sent events.
2. A true viewmodel based page composition framework, where components are abstract view elements with data bindings on the server side, which then have associated renderers for the output to the client.
I've played with both of these, and found them to have a lot of advantages over standard template + ajax + callbacks style of design, though creating a library for others is a lot more work than hacking something for yourself :)
It's ridiculous to act like the mere existence of multiple independent projects for one task is some kind of searing indictment of the "one obvious way" principle in language and API design.
I prefer Perl's approach of embracing more than one way to do things. I don't really want there to be 8 ways to do one thing, but it's just a more realistic outlook. You go into Perl knowing that you are going to have to try a bunch of different things to see what fits your mental model, instead of being told what to do. (I used Python at a Bank where they wrote their own style guide, completely different from the standard Python style guide. WTF? Humans have a way of ruining everything.)
Ironically, many things in Perl have converged into "One Obvious Way"; PSGI/Plack for web frameworks, Test::Builder for unit tests, and so on.
There are always more than 1 ways to do something, but Python tries to be directive towards the recommended way for the core.
For the given snippet, using reduce for loops is frowned upon; nothing is stopping you from doing it, but the general opinion is you shouldn't do it. I think that counts as there being an obvious way.
def pipe(val, fns):
return reduce(lambda val, fn: fn(val), fns, val)
def pipe2(val, fns):
for fn in fns:
val = fn(val)
return val
fns = [lambda x: x + 1, lambda x: x * x]
print pipe(5, fns)
print pipe2(5, fns)
<nitpick> Twisted(reactors) and threads implement two different things which serve different purposes, and unittest2 is a lib while nose is a test runner. </nitpick>
That said, there is always going to be many ways to do something, but it helps if the core tries to stick with a uniform way to do things.
This is also an article from 2006.
Here's wiki on it: http://en.wikipedia.org/wiki/Kid_%28templating_language%29