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

11–20 of 61 posts

Re: Why so many Python web frameworks?

#11

Post by hello_moto »

anthonyb wrote: post #8
fennecfoxen wrote: post #5

Earlier quoted context omitted.

Rumor (and by rumor I mean a couple of opinionated coworkers) says: the Python community has a lot of cases of "This project didn't have the feature I needed and has a couple of problems, so I went and wrote a whole new one with a different set of problems." By contrast, the Ruby community settles down on one, maybe two things as the primary way to do it. This article lends weight to the rumor.

It works the way that most open source third party libraries do: There'll initially be some hacked together stuff, then a couple of contenders will emerge, copying each other's features. After the dust has settled there'll be a few decent libraries. 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 standa…

Yep, except nobody cares about "the rest" and Rails becomes almost de-facto choice for web-app with Sinatra trailing for the so-called "API" project (whether that choices make sense or not is not of my concern, in Java, API == XYZService.java with a facade skeleton implementation utilizing JAX-WS [SOAP, WS-*], JAX-RS [RESTful], or Servlet (Web) all deployable easily in 1 JAR).

Re: Why so many Python web frameworks?

#12

Post by unimpressive »

wycats wrote: post #3

Doesn't making a new X because it's easy violate the "There should be one-- and preferably only one --obvious way to do it" rule? 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.

If you read to the end of the article it tells you (Implies) that making Yet Another X is a bad idea, and that you should really go work on an already established project.

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

Re: Why so many Python web frameworks?

#13

Post by reactor »

wycats wrote: post #3

Doesn't making a new X because it's easy violate the "There should be one-- and preferably only one --obvious way to do it" rule? 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.

"There should one - and preferably only one - obvious way to do it" is applicable only at language level, not at application level. These are just another applications and one cannot enforce a rule that "there should be only one application/solution for a problem at hand", is it ?

Re: Why so many Python web frameworks?

#14

Post by anthonyb »

hello_moto wrote: post #11
anthonyb wrote: post #8

Earlier quoted context omitted.

It works the way that most open source third party libraries do: There'll initially be some hacked together stuff, then a couple of contenders will emerge, copying each other's features. After the dust has settled there'll be a few decent libraries. 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 standa…

Yep, except nobody cares about "the rest" and Rails becomes almost de-facto choice for web-app with Sinatra trailing for the so-called "API" project (whether that choices make sense or not is not of my concern, in Java, API == XYZService.java with a facade skeleton implementation utilizing JAX-WS [SOAP, WS-*], JAX-RS [RESTful], or Servlet (Web) all deployable easily in 1 JAR).

Well, ditto with Python and Django these days. There are other frameworks, each with their own strengths (werkzeug, web.py, bottle, etc.), but Django is the default choice.

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

Re: Why so many Python web frameworks?

#15

Post by anthonyb »

espeed wrote: post #2

Building a non-WSGI Python framework would be useful because WSGI does not support websockets ( http://librelist.com/browser//flask/2011/12/30/websockets/#b... ). 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.

Eventlet seems to support it: http://blog.eventlet.net/2010/02/12/scalable-wsgi-compatible...

Re: Why so many Python web frameworks?

#16

Post by sekou »

It may be easy to link together well developed Python libraries for web development, I think it's one of the benefits of working in Python, but full stack frameworks like Django that provide a somewhat unified API exist at least in my mind on a different level of framework. I think there is a spectrum of complexity represented in the list of frameworks linked by the author, and the word "framework" is used to describe a lot of different kinds of situations.

Re: Why so many Python web frameworks?

#17

Post by FraaJad »

wycats wrote: post #3

Doesn't making a new X because it's easy violate the "There should be one-- and preferably only one --obvious way to do it" rule? 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.

There is a difference between reducing entropy in core language vs individual developers' freedom to build things (libs, frameworks) as they see fit.

Your comment is surprising given your expertise. Guess you are not immune to taking pot shots at Python.

Re: Why so many Python web frameworks?

#18

Post by DasIch »

wycats wrote: post #3

Doesn't making a new X because it's easy violate the "There should be one-- and preferably only one --obvious way to do it" rule? 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 rule applies to the language and APIs on a project level but it doesn't extend beyond that.

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.

Re: Why so many Python web frameworks?

#19

Post by DasIch »

anthonyb wrote: post #14
hello_moto wrote: post #11

Earlier quoted context omitted.

Yep, except nobody cares about "the rest" and Rails becomes almost de-facto choice for web-app with Sinatra trailing for the so-called "API" project (whether that choices make sense or not is not of my concern, in Java, API == XYZService.java with a facade skeleton implementation utilizing JAX-WS [SOAP, WS-*], JAX-RS [RESTful], or Servlet (Web) all deployable easily in 1 JAR).

Well, ditto with Python and Django these days. There are other frameworks, each with their own strengths (werkzeug, web.py, bottle, etc.), but Django is the default choice. 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 op…

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 project would ever claim that.

Re: Why so many Python web frameworks?

#20

Post by warp »

ak217 wrote: post #6
espeed wrote: post #2

Building a non-WSGI Python framework would be useful because WSGI does not support websockets ( http://librelist.com/browser//flask/2011/12/30/websockets/#b... ). 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.

I'm really interested in this for building simple API endpoints. I tried a bunch of WSGI servers and lightweight frameworks to serve stuff on them, but realized that there is no way to support chunked request content encoding with WSGI (the WSGI spec is not compatible with it, so WSGI can't support HTTP/1.1). Hopefully Brubeck is good, please let us know if there's anything else worth checking out!

That doesn't sound correct. Both PEP 333 and 3333 specifically mention that the server may use chunked encoding.
Post reply on HN