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/python/yet-another-comparison-of-web-frameworks.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.

 

[Lawrence Oluyede]

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 ;-)
?

 

[Tim Chase]

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

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]

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]

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.

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/python/yet-another-comparison-of-web-frameworks.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]

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

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

Not reinventing the wheel just don't feel as a universal dogma to me. I
developed quite a bit with Django and I was glad they started from
scratch. On the paper reusing different and existing projects is great
but not always is good or done the right way. Anyway I don't know TG at
all so I'm speaking in a figurative way.

We (Michele, myself and our colleagues) have a series of stuff we need
to stick to so the choosing of a web framework ain't that easy. Most of
the frameworks are a vision of the author of how to do things from
scratch but a framework (by definition an evolution of a library) is not
always meant to be used when the scratch is far from your starting
point.

I'd like to read some commenting of Michele's thoughts, they would be
really useful.

 

[Lawrence Oluyede]

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

 

[Kay Schluehr]

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

+1 QOTW

 

[Bruno Desthuilliers]

Michele Simionato a écrit :

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

To me, yes - but the context probably makes some difference here.
Anyway, even for apps I developped with older versions of Django or for
Trac plugins, I missed this feature. I like being able to reorganize my
url space, and having urls knowldege all over is very bad IMHO. While
perhaps not the ultimate solution (is there one), routes does a good job
with this IMHO.

(snip)

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

Then rejoice : you'll have a better package to test, with better
documentation !-)

Do you (or something else) have something to say about Beaker?

Sorry, not so far. As I mentionned, I had to delay serious work with
Pylons so far.

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

Can't tell, but I'd trust the Pylons team on this kind of choices.
They're doing good job so far AFAICT.

 

[Michele Simionato]

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

Can't tell, but I'd trust the Pylons team on this kind of choices.
They're doing good job so far AFAICT.[/QUOTE]

Probably Beaker works well, but it is certainly NOT doing things
as Eby recommends:

http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html

BTW, I know that Eby is asking opinions about WSGI 2.0 on the
WSGI SIG and interested people may have a look there.

Michele Simionato

 

[genro]

On Oct 6, 12:57 pm, Bruno Desthuilliers



Probably Beaker works well, but it is certainly NOT doing things
as Eby recommends:

http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html

BTW, I know that Eby is asking opinions about WSGI 2.0 on the
WSGI SIG and interested people may have a look there.

Michele Simionato

I think that Beaker is a Mako dependency.
So if you use Mako, Beaker is not an option

G

 

[Steve Holden]

Not reinventing the wheel just don't feel as a universal dogma to me. I
developed quite a bit with Django and I was glad they started from
scratch. On the paper reusing different and existing projects is great
but not always is good or done the right way. Anyway I don't know TG at
all so I'm speaking in a figurative way.

We (Michele, myself and our colleagues) have a series of stuff we need
to stick to so the choosing of a web framework ain't that easy. Most of
the frameworks are a vision of the author of how to do things from
scratch but a framework (by definition an evolution of a library) is not
always meant to be used when the scratch is far from your starting
point.

I'd like to read some commenting of Michele's thoughts, they would be
really useful.

Porting existing web applications to new architectures requires more
than just transliteration, since you lose some metaphors available only
in the donor system and may therefore need to take advantage of new
idioms in the new environment to compensate.

I spent some time trying to re-architect the code from "Python Web
Programming" in TurboGears. That was difficult not because TG is a bad
system but because there was an impedance mismatch between the original
code's framework and the way TG does things.

I guess I would have similar problems with Django.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline so I couldn't cat it

 

[Bruno Desthuilliers]

Steve Holden a écrit :

Lawrence Oluyede wrote: (snip)
Porting existing web applications to new architectures requires more
than just transliteration, since you lose some metaphors available only
in the donor system and may therefore need to take advantage of new
idioms in the new environment to compensate.

I spent some time trying to re-architect the code from "Python Web
Programming" in TurboGears. That was difficult not because TG is a bad
system but because there was an impedance mismatch between the original
code's framework and the way TG does things.

I guess I would have similar problems with Django.

Indeed. But AFAICT, Lawrence and Michele problems is not to port an
existing web application, but to choose a web framework that will play
well with their existing *system* (RDBMS, existing apps and libs etc).
Which is quite another problem, and may eliminate some otherwise pretty
good frameworks for compatibility reasons (DBMS support and other issues).

(please Michele or Lawrence correct me if I'm wrong...)

 

[Michele Simionato]

On Oct 7, 8:36 am, Bruno Desthuilliers

Indeed. But AFAICT, Lawrence and Michele problems is not to port an
existing web application, but to choose a web framework that will play
well with their existing *system* (RDBMS, existing apps and libs etc).
Which is quite another problem, and may eliminate some otherwise pretty
good frameworks for compatibility reasons (DBMS support and other issues).

(please Michele or Lawrence correct me if I'm wrong...)

Yes, our main concern is compatibility with the existing
system: for instance, one constraint is the MS SQL database.
Having said that, we would like to port parts of a Zope application to
the new framework, but I do not expect this to be
particularly difficult for the parts we want to migrate since
they are not really using Zope features. Other parts instead
would require a very substantial rewrite so for the moment I think
they will stay in Zope.

Michele Simionato

 

[Istvan Albert]

IMO this is not as much a framework comparison rather than an
evaluation of the individual components that make up Pylons.

The framework is the sum of all its parts. Programmers should not need
to know that that a package named Beaker is used for sessions, Routes
for url mapping, PasteDeploy for whatever. This is the weakness of all
glue-type frameworks i.e. TG and Pylons. It makes them look like they
are duct-taped together.

The more important question are whether the sessions actually work
properly: i.e does session data persist through a server restart?
Where is the session data stored: in memory, files, database and so
on.

The choice of templating language should be a non issue. Any half
decent framework should allow you to use any other templating engine
with ease.
.... even python as you seem to prefer

i.

 

[Michele Simionato]

IMO this is not as much a framework comparison rather than an
evaluation of the individual components that make up Pylons.

More in general let's say that I am interested in the evaluation
of WSGI-compatible components.

The framework is the sum of all its parts. Programmers should not need
to know that that a package named Beaker is used for sessions, Routes
for url mapping, PasteDeploy for whatever. This is the weakness of all
glue-type frameworks i.e. TG and Pylons. It makes them look like they
are duct-taped together.

Here we disagree: I think that a programmer should know what he
is using. Moreover I think that composability is good since you
can understand the components one at the time and replace one
component with another according to your needs. OTOH, it is
true that duct-taped framework have some weak points, I am
the first to recognize that. But I also think the issues
will be less and less relevant as time goes by and the
culture of composable frameworks will become more widespread
in the community.

The more important question are whether the sessions actually work
properly: i.e does session data persist through a server restart?
Where is the session data stored: in memory, files, database and so
on.

Of course Beaker has all these features and I have no reasons
to believe they will not work.

The choice of templating language should be a non issue. Any half
decent framework should allow you to use any other templating engine
with ease.
... even python as you seem to prefer

Yes, the choice of templating language is a non-issue. Maybe
I should have removed my considerations on the subject in
my essay, just to avoid the bikeshed effect.

Michele Simionato