Yet another comparison of Python Web Frameworks

[Michele Simionato]

At work we are shopping for a Web framework, so I have been looking at
the available options
on the current market. In particular I have looked at Paste and Pylons
and I have written my
impressions here:

http://www.phyast.pitt.edu/~micheles...rameworks.html

I do not speak too well of Pylons, so if you thing I am wrong feel
free to correct me here ;)
Michele Simionato

[Thomas Wittek]

Michele Simionato:

At work we are shopping for a Web framework, so I have been looking at
the available options
on the current market.

At least, you missed Turbo Gears :)
http://turbogears.org/
For me, it feels more integrated than Pylons.

--
Thomas Wittek
Web: http://gedankenkonstrukt.de/
Jabber: st*********@jab ber.i-pobox.net
GPG: 0xF534E231

[Lawrence Oluyede]

Thomas Wittek <ma**@gedankenk onstrukt.dewrot e:

At least, you missed Turbo Gears :)
http://turbogears.org/
For me, it feels more integrated than Pylons.

Yeah, so integrated that the next version will be based upon Pylons ;-)
?

--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair

[Tim Chase]

>At work we are shopping for a Web framework, so I have been

>looking at the available options on the current market.

At least, you missed Turbo Gears :)
http://turbogears.org/
For me, it feels more integrated than Pylons.

Django [1] barely gets anything more than a mention as well.

Any respectable comparison of Python web frameworks should
include evaluation of at least Django and TG. Or at least give
good reason why the comparison excludes them.

Zope is also missing, but I'm not sure Zope qualifies so much as
a framework, but as an answer to the question "If Emacs were a
Python web environment, what would it look like?"

I chose Django, but saw the power in TG as well...from my testing
of them, Django has a nice unified OOB experience, while TG feels
like it's trying to rein in very strong, but disparate parts.
Django's built-in templating system is one of those things you
either love or you hate. Fortunately, if you're a hater, you can
mindlessly swap it out for your template system of choice with
minimal fuss.

-tim

[1] http://www.djangoproject.com

[Jorge Godoy]

Tim Chase wrote:

Any respectable comparison of Python web frameworks should
include evaluation of at least Django and TG. Or at least give
good reason why the comparison excludes them.

When he said that he didn't want anything complex neither anything that used
a templating system, I thought this had already excluded a lot of
frameworks, including TG and Django.

Zope is also missing, but I'm not sure Zope qualifies so much as
a framework, but as an answer to the question "If Emacs were a
Python web environment, what would it look like?"

He already had dislikings with Plone that weren't clear, maybe a lot of
those are Zope related...
I agree, though, that more time could be spent explaining "why" things were
discarded / ignored.

[Jorge Godoy]

Lawrence Oluyede wrote:

Thomas Wittek <ma**@gedankenk onstrukt.dewrot e:

>At least, you missed Turbo Gears :)
http://turbogears.org/
For me, it feels more integrated than Pylons.

Yeah, so integrated that the next version will be based upon Pylons ;-) ?

What is good, since a lot of good things from Pylons will work with TG and a
lot of good TG things will remain (and possibly be compatible with Pylons).
If you take a better look at "the next version", you'll also see that the
major concern was with WSGI support and reinventing / "rewriting" the wheel
(what TG developers don't want to do all the time).

As an example of this fusion, take a look at ToscaWidgets. Works, *today*,
with both frameworks. You don't have to wait for "the next version".

[Michele Simionato]

On Oct 6, 7:15 am, Jorge Godoy <jgo...@gmail.c omwrote:

Tim Chase wrote:

Any respectable comparison of Python web frameworks should
include evaluation of at least Django and TG. Or at least give
good reason why the comparison excludes them.

Mine is not a respectable comparison of Web frameworks, it is
NOT intended to be so. It is just a set of notes I kept for
myself and that may be or may be not of interest to others.

When he said that he didn't want anything complex neither anything that used
a templating system, I thought this had already excluded a lot of
frameworks, including TG and Django.

This is clearly not true, since I could use these frameworks
without using their templates if I wanted. It would be very
stupid to dismiss an entire framework only because I dislike
its templates.

Zope is also missing, but I'm not sure Zope qualifies so much as
a framework, but as an answer to the question "If Emacs were a
Python web environment, what would it look like?"

He already had dislikings with Plone that weren't clear, maybe a lot of
those are Zope related...

I agree, though, that more time could be spent explaining "why" things were
discarded / ignored.

Look, there are already tons of pages on the net ranting against
Zope, my complaints are quite common and I have no interest
in repeating what has been already said. For instance, if you
Google a bit you should find the rants of the Quixote people
against Zope. I share their position.
I did not talk about TG because I see it as being very close to
Pylons and everybody is saying they will be unified in the near
future, so it would be a waste of effort to discuss TG per se.

Michele Simionato

[Bruno Desthuilliers]

Michele Simionato a écrit :

At work we are shopping for a Web framework, so I have been looking at
the available options
on the current market. In particular I have looked at Paste and Pylons
and I have written my
impressions here:

http://www.phyast.pitt.edu/~micheles...rameworks.html

I do not speak too well of Pylons, so if you thing I am wrong feel
free to correct me here ;)

Well... Last year, I had a look at Pylons, then played a bit with wsgi
and building my own framework over it. I finally dropped that code and
went back to Pylons, which I felt could become far better than my own
efforts. Now since then I had way too much to do at work (using other
technos) and didn't find the time to work on my own projects, so I still
don't know how well Pylons will pass the "real world" test, but it seems
to me that it's rapidly progressing and mostly in the right direction. I
still wait for an opportunity to check this out !-)

While we're at it:

- talking about routes, you say:

"""
I have no Ruby On Rails background, so I don't see the advantages of routes.
"""

I don't have any RoR neither, but as far as I'm concerned, one of the
big points with routes is url_for(), that avoids having too much
hard-coded urls.

- about FormEncode : that's a package I've used before without Pylons,
and while it has a few dark corners, it's mostly doing TheRightThing for
most current validation/conversion tasks. I'll still use it with or
without Pylons

- about SQLAlchemy : here again, I used this package prior any
experience with Pylons. FWIW, I used it in the most basic, 'low-level'
way, ie without any ORM stuff, and I found it to be a pretty good
alternative to db-api. It's a bit complex, but powerful, and having the
possibility to handle sql requests as Python objects (instead of raw
strings) really helps.

[Michele Simionato]

On Oct 6, 9:13 am, Bruno Desthuilliers <bruno.
42.desthuilli.. [e-mail] ro.oops.comwrot e:

- talking about routes, you say:

"""
I have no Ruby On Rails background, so I don't see the advantages of routes.
"""

I don't have any RoR neither, but as far as I'm concerned, one of the
big points with routes is url_for(), that avoids having too much
hard-coded urls.

Well, url_for is convenient, I would not deny it. Still it is
not compelling to me.

- about FormEncode : that's a package I've used before without Pylons,
and while it has a few dark corners, it's mostly doing TheRightThing for
most current validation/conversion tasks. I'll still use it with or
without Pylons

- about SQLAlchemy : here again, I used this package prior any
experience with Pylons. FWIW, I used it in the most basic, 'low-level'
way, ie without any ORM stuff, and I found it to be a pretty good
alternative to db-api. It's a bit complex, but powerful, and having the
possibility to handle sql requests as Python objects (instead of raw
strings) really helps.

I have wanted to do a serious test of SQLAlchemy for a
couple of years, but never found the time :-(

Do you (or something else) have something to say about Beaker?
I looked at the source code and it seems fine to me, but I have
not used it directly, not stressed it. I need a
production-level WSGI session middleware and I wonder what the
players are (for instance how Beaker does compare with flup?)

Michele Simionato

[Lawrence Oluyede]

Tim Chase <py*********@ti m.thechases.com wrote:

Any respectable comparison of Python web frameworks should
include evaluation of at least Django and TG. Or at least give
good reason why the comparison excludes them.

I think you didn't read the foreword of the comparison. That is by no
means a comprehensive comparison and is not meant to be one. Is a series
of thoughts about the frameworks we already tried (we don't have to
decide today) and the ones we experimented with. Django is not
completely off the radar because I used it extensively this year but the
company has certain requirements and the full stackness of Django is not
really one of our needs.

Zope is also missing, but I'm not sure Zope qualifies so much as
a framework, but as an answer to the question "If Emacs were a
Python web environment, what would it look like?"

Zope2/Plone2 is the one framework they are running away from :-)
More KISS less over engineering, that's the mantra.

Django's built-in templating system is one of those things you
either love or you hate. Fortunately, if you're a hater, you can
mindlessly swap it out for your template system of choice with
minimal fuss.

I really, really like Django (and its community and the competence of
the developers) and I think it deserves what it has gained and more but
we are not here to decide who's the best (there's always no best).

--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair