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

Why so many Python web frameworks?

bitworking.org

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Why so many Python web frameworks?

#51

Post by tbatterii »

reuser wrote: post #38
DasIch wrote: post #19

Earlier quoted context omitted.

While some people may choose Django per default, there are also quite a lot of people that will choose Flask/Werkzeug, Pyramid or one of the less popular frameworks. 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 pro…

Django has such numeric superiority that there is not a lot of point splitting hairs on whether it is "default." While it isn't in the stdlib and there are other good choices, Django might as well be the default, just as Rails might as well be the default in Ruby.

You sure about that? It is my understanding that Zope/Plone has a fairly sizable community. They're just not as loud on the web as other framework fans. No one will know for sure until they are all counted though.

Re: Why so many Python web frameworks?

#52

Post by irahul »

Chris_Newton wrote: post #46
irahul wrote: post #35

While we are at the topic of Python web frameworks, I seriously like Flask's design better than django's. True that django came out before SQLAlchemy or Jinja2 became popular/existed, but I would have loved it had they re-factored. 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…

We've been using Flask recently, and I do like the simple, no-nonsense approach. Our project is modest in its library needs, and it's nice to have a useful toolkit without imposing a heavyweight structure on our code. 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…

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.

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.

Re: Why so many Python web frameworks?

#53

Post by NathanRice »

A lot of people will make snide remarks when someone says they are creating their own framework, but obviously if someone has evaluated the existing frameworks and still decides to do it, there is an unscratched itch. A lot of people who aren't happy with the larger monolithic frameworks have adopted flask (myself included) as a simple base to build more interesting things on.

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 :)

Re: Why so many Python web frameworks?

#55

Post by Chris_Newton »

irahul wrote: post #52
Chris_Newton wrote: post #46

Earlier quoted context omitted.

We've been using Flask recently, and I do like the simple, no-nonsense approach. Our project is modest in its library needs, and it's nice to have a useful toolkit without imposing a heavyweight structure on our code. 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…

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. Depending on your use case, you can either use X-sendfile header - valida…

Thanks for the suggestions.

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.

Re: Why so many Python web frameworks?

#56

Post by jrockway »

reuser wrote: post #39
jrockway wrote: post #23

Because Python's motto is "There's more than one way to do it."

People writing tools to learn, or because the existing ones didn't suit their needs or tastes, occurs in every language and is very different from Perl-style "more than one way to do it". 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've never actually noticed "one obvious way". There are a couple ways to do almost everything in Python; loops or map, Twisted or threads, unittest2 or nose, and so on. I like Python, but human nature pushes everything towards "there are many ways to do it", and humans have influenced the direction of Python.

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.

Re: Why so many Python web frameworks?

#57

Post by irahul »

Chris_Newton wrote: post #55
irahul wrote: post #52

Earlier quoted context omitted.

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. Depending on your use case, you can either use X-sendfile header - valida…

Thanks for the suggestions. 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.

> 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...

Re: Why so many Python web frameworks?

#58

Post by irahul »

jrockway wrote: post #56
reuser wrote: post #39

Earlier quoted context omitted.

People writing tools to learn, or because the existing ones didn't suit their needs or tastes, occurs in every language and is very different from Perl-style "more than one way to do it". 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've never actually noticed "one obvious way". There are a couple ways to do almost everything in Python; loops or map, Twisted or threads, unittest2 or nose, and so on. I like Python, but human nature pushes everything towards "there are many ways to do it", and humans have influenced the direction of Python. I prefer Perl's approach of embracing more than one way to do things. I don't really want there to be 8 ways…

> There are a couple ways to do almost everything in Python; loops or map, Twisted or threads, unittest2 or nose, 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)
As far as maps and list comprehension go, that isn't clear-cut but people incline towards comprehensions.

Twisted(reactors) and threads implement two different things which serve different purposes, and unittest2 is a lib while nose is a test runner.

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.

Re: Why so many Python web frameworks?

#59

Post by reuser »

tbatterii wrote: post #51
reuser wrote: post #38

Earlier quoted context omitted.

Django has such numeric superiority that there is not a lot of point splitting hairs on whether it is "default." While it isn't in the stdlib and there are other good choices, Django might as well be the default, just as Rails might as well be the default in Ruby.

You sure about that? It is my understanding that Zope/Plone has a fairly sizable community. They're just not as loud on the web as other framework fans. No one will know for sure until they are all counted though.

I'm heuristically pretty sure. From my personal experience talking to people, and from some surveys or other I have casually looked at over the years, what is mentioned most in job ads and mailing lists, heuristic stuff like that. The same kind of stuff which leads people to say that Rails is much more popular than other Ruby frameworks.

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.

Re: Why so many Python web frameworks?

#60

Post by Chris_Newton »

irahul wrote: post #57
Chris_Newton wrote: post #55

Earlier quoted context omitted.

Thanks for the suggestions. 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.

> 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; an…

I was referring to the sendfile system call there. We've seen reports that on some versions of Linux kernel, it doesn't work, for some value of "doesn't work" that we haven't yet properly determined. We've also seen web pages that suggest Flask's send_file and send_from_directory would ultimately rely on that system call in some circumstances, though again I haven't checked through the code in detail yet so I don't know how accurate those reports are.

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.)

Post reply on HN