Home » Coding » Python » Yet another comparison of Python Web Frameworks
| Yet another comparison of Python Web Frameworks [message #15506] |
Sat, 06 October 2007 04:33  |
 Michele Simionato
Messages: 60
Registered: August 2007 |
Member |
|
|
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-comp arison-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
|
|
| | |
| Re: Yet another comparison of Python Web Frameworks [message #15516 is a reply to message #15506 ] |
Sat, 06 October 2007 07:06  |
Tim Chase
Messages: 21
Registered: September 2007 |
Junior Member |
|
|
>> 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
|
|
| | |
| Re: Yet another comparison of Python Web Frameworks [message #15522 is a reply to message #15520 ] |
Sat, 06 October 2007 08:02 |
Michele Simionato
Messages: 60
Registered: August 2007 |
Member |
|
|
On Oct 6, 7:15 am, Jorge Godoy <jgo...@gmail.com> wrote:
> 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
|
|
|
| Re: Yet another comparison of Python Web Frameworks [message #15534 is a reply to message #15506 ] |
Sat, 06 October 2007 09:13 |
Bruno Desthuilliers
Messages: 277
Registered: July 2007 |
Senior Member |
|
|
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-comp arison-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.
|
|
|
| Re: Yet another comparison of Python Web Frameworks [message #15538 is a reply to message #15534 ] |
Sat, 06 October 2007 09:29 |
Michele Simionato
Messages: 60
Registered: August 2007 |
Member |
|
|
On Oct 6, 9:13 am, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.com> wrote:
> - 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
|
|
| | | |
| Re: Yet another comparison of Python Web Frameworks [message #15562 is a reply to message #15538 ] |
Sat, 06 October 2007 12:57 |
Bruno Desthuilliers
Messages: 277
Registered: July 2007 |
Senior Member |
|
|
Michele Simionato a écrit :
> On Oct 6, 9:13 am, Bruno Desthuilliers <bruno.
> 42.desthuilli...@wtf.websiteburo.oops.com> wrote:
>> - 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.
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)
>> - 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 :-(
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.
|
|
| |
| Re: Yet another comparison of Python Web Frameworks [message #15627 is a reply to message #15608 ] |
Sun, 07 October 2007 05:33 |
genro
Messages: 2
Registered: September 2007 |
Junior Member |
|
|
On Oct 7, 8:35 am, Michele Simionato <michele.simion...@gmail.com>
wrote:
> On Oct 6, 12:57 pm, Bruno Desthuilliers
>
> > Michele Simionato a écrit :
>
> > > 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.
>
> Probably Beaker works well, but it is certainly NOT doing things
> as Eby recommends:
>
> http://dirtsimple.org/2007/02/wsgi-middleware-considered-har mful.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
|
|
| | |
| Re: Yet another comparison of Python Web Frameworks [message #15667 is a reply to message #15663 ] |
Sun, 07 October 2007 08:49 |
Michele Simionato
Messages: 60
Registered: August 2007 |
Member |
|
|
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
|
|
| |
| Re: Yet another comparison of Python Web Frameworks [message #15748 is a reply to message #15711 ] |
Sun, 07 October 2007 12:24 |
Michele Simionato
Messages: 60
Registered: August 2007 |
Member |
|
|
On Oct 7, 11:31 am, Istvan Albert <istvan.alb...@gmail.com> wrote:
> 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
|
|
| |
| Re: Yet another comparison of Python Web Frameworks [message #17461 is a reply to message #17441 ] |
Mon, 08 October 2007 00:58 |
Michele Simionato
Messages: 60
Registered: August 2007 |
Member |
|
|
On Oct 7, 6:14 pm, Istvan Albert <istvan.alb...@gmail.com> wrote:
> On Oct 7, 12:24 pm, Michele Simionato <michele.simion...@gmail.com>
> wrote:
>
> > Here we disagree: I think that a programmer should know what he
> > is using.
>
> My point was that they should not *need* to know. Too much information
> can be detrimental.
Actually, in principle I *do* agree with you. For instance,
when I type 1+1, I have no idea of what exactly Python is
doing, but I don't need to know, because adding two integers
is a problem which is well understood and has been solved by
others years ago, I don't need to care about it. I wait with
impatience the time when Web programming will become a solved
problem with a standard built-in solution that works.
Unfortunately, that time is not near in the future and for the
moment I am forced to know how all the pieces work if I want to
build a reliable application. I don't like it, since I am not
particularly interested in the low levels and in the plumbings
myself, but this is the way it is.
> ... truth to
> be told I was just curious of how they would go about integrating a
> database and still keep it "pluggable".
>
> Because it would either need to know about the way the server handles
> the database connections (which makes it application specific) or it
> has to create new database connections in which case it would be
> duplicating the functionality leading to all kinds of headaches.
>
> So there, even a simple requirement exposes the fallacy of building
> anything complex out of "pluggable" components.
I suppose Beaker rely on SQLAlchemy since it comes from the
same mind, but I don't see the issue: a component may well
depend from another one, partially or totally, but this
does not detract at all from the usefulness of the component
approach. If I don't need persistent on a database, for instance,
I like to have the choice between a full-fledged component
and a poor man component that satisfies my basic requirements
and nothing more. I don't want to be forced to use a
monolithic-good-for-everybody solution.
Michele Simionato
|
|
|
| Re: Yet another comparison of Python Web Frameworks [message #17466 is a reply to message #17461 ] |
Mon, 08 October 2007 02:00 |
John Nagle
Messages: 29
Registered: August 2007 |
Junior Member |
|
|
Michele Simionato wrote:
> I wait with
> impatience the time when Web programming will become a solved
> problem with a standard built-in solution that works.
That will probably come from Microsoft. At least for
all-Microsoft environments. They're the only player who
controls enough of the pieces.
John Nagle
|
|
|
Goto Forum:
Current Time: Fri May 16 02:58:32 EDT 2008
Total time taken to generate the page: 2.23276 seconds |
Members
Search
Help
Register
Login
Home
