Which Python web framework is most like Ruby on Rails?

[Robert Kern]

I agree with chuck. I've seen excellent programmers explain why for
some urgent problem they chose Ruby on Rails rather than Java or Python:
Ruby has ONE web framework (that matters), so the choice was finished
there; to evaluate properly 50 frameworks for Java or 20 for Python
would have taken weeks or months...

That doesn't make much sense, no matter how excellent those programmers were. If
Java and Python were ever on the table, then those 50 or 20 other frameworks
would still need to be evaluated *with* RoR.

Picking RoR because you want to do the project in Ruby makes sense. Picking Ruby
because it only has one web framework is as silly as picking one Python web
framework at random. Just because RoR is the only Ruby web framework around
doesn't mean it's suitable for every project.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Alex Martelli]

Picking RoR because you want to do the project in Ruby makes sense.
Picking Ruby because it only has one web framework is as silly as picking
one Python web framework at random. Just because RoR is the only Ruby web
framework around doesn't mean it's suitable for every project.

If you claim there's a web project that's unfeasible to do in Ruby,
you'd better come up with a strong example. If you're making no such
claim, which would be counter to the claims of the Ruby community, then
there aren't gonna be any web projects unfeasible with Rails, either.

The multiplicity of frameworks in Python obviously makes the situation
very different: there might well be projects for which Python's quite
suitable IF a fairy godmother pointed you to just the right framework...
but lacking a fairy godmother, you're out of luck.

To put it another way: one reason I love Python is that I strongly
subscribe to the idea that there should preferably be only one obvious
way to do something. Unfortunately, this principle is very badly broken
by the multiplicity of Python web frameworks.


Alex

 

[Paul Rubin]

To put it another way: one reason I love Python is that I strongly
subscribe to the idea that there should preferably be only one obvious
way to do something. Unfortunately, this principle is very badly broken
by the multiplicity of Python web frameworks.

This also has to be a big part of why PHP is kicking the pants off of
Python for popularity in web development.

 

[Alex Martelli]

This also has to be a big part of why PHP is kicking the pants off of
Python for popularity in web development.

Sure, that's possible. Differently from Ruby (which is quite a
reasonable language, so I can see how some might prefer it to Python),
it would IMNSHO be unreasonable to claim *language* preference for that
case;-).


Alex

 

[Robert Kern]

If you claim there's a web project that's unfeasible to do in Ruby,
you'd better come up with a strong example. If you're making no such
claim, which would be counter to the claims of the Ruby community, then
there aren't gonna be any web projects unfeasible with Rails, either.

Since web programming isn't my bailywick, I'll back off any specific claim about
unsuitability. That said, I am always suspicious about such claims of
universality in what seems to be a relatively broad field. It seems to me that
such claims bear a greater burden of proof. I recall such rhetoric in the early
days of Zope. It didn't quite pan out that way.

The multiplicity of frameworks in Python obviously makes the situation
very different: there might well be projects for which Python's quite
suitable IF a fairy godmother pointed you to just the right framework...
but lacking a fairy godmother, you're out of luck.

We've got a few fairy godmothers.

http://pyre.third-bit.com/pyweb/index.html
http://colorstudy.com/docs/shootout.html

My question is this: Why doesn't one need a fairy godmother to pick from the set
{RoR, Zope, TurboGears, CherryPy, ...}? Or rather, why is "Here's a framework
which is the only one to be implemented in a particular language," a good fairy
godmother? Why doesn't *that* process take a few months of evaluation?

To put it another way: one reason I love Python is that I strongly
subscribe to the idea that there should preferably be only one obvious
way to do something. Unfortunately, this principle is very badly broken
by the multiplicity of Python web frameworks.

Believe me, I'm all in favor of condensing the number of Python web frameworks
or making the currently available fairy godmothers better. I'm not arguing
against that. It's just that the decision process that you described seemed to
me to be flawed.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Mike Meyer]

If you claim there's a web project that's unfeasible to do in Ruby,
you'd better come up with a strong example. If you're making no such
claim, which would be counter to the claims of the Ruby community, then
there aren't gonna be any web projects unfeasible with Rails, either.

There's a difference between "feasible" and "suitable". The claim that
everything is feasible with RoR is trivially true because Ruby - and
hence RoR - is presumably turing complete. But this claim is
uninteresting.

The *interesting* claim is "RoR is suitable for all web projects."
That's not trivially true. My experience with other web platforms -
both built around Python and not - is that this claim has very much in
common with the claim "X is suitable for all programming projects",
for some programming language X. I don't believe such a programming
language exists (though proving that is well-nigh impossible), and I'm
pretty confident that such a web platform doesn't exist, though the
problem space hasn't existed for long enough to be sure.

Of course, I don't know RoR. If you've got a pointer to a discussion
of the kinds of things RoR is good for, I'd appreciate it. Googling
turns up tutorials, and that's all.

The multiplicity of frameworks in Python obviously makes the situation
very different: there might well be projects for which Python's quite
suitable IF a fairy godmother pointed you to just the right framework...
but lacking a fairy godmother, you're out of luck.

I did a fairly thorough investigation of web frameworks that let us
write Python (we didn't care what the framework was written in; merely
that it interfaced with Python) for one of the systems I've built this
year. I wouldn't call the evaluation of web frameworks a problem - we
met our schedules, and the tool evaluation phase was by *far* the
shortest phase in the project, taking less than a week. Most of the
evaluations were easy - read the description of the framework, and
decide that we're working outside the problem space it's desinged
for. It certainly wasn't wasted time - I found a tool that I hadn't
heard of previously that was nearly perfectly suited to the job at
hand.

To put it another way: one reason I love Python is that I strongly
subscribe to the idea that there should preferably be only one obvious
way to do something. Unfortunately, this principle is very badly broken
by the multiplicity of Python web frameworks.

The problem is that "building a web site" is a single "something" in
the same way that "writing a computer program" is a single
"something". Each represents a wide range of different problems, and
the obvious way to do one of those something may not be the obvious
way to do another of them.

<mike

 

[gene tani]

http://pyre.third-bit.com/pyweb/index.html
http://colorstudy.com/docs/shootout.html

i started flipping thru "Snakes and rubies" google hits now at 127k,
waaay up from yesterday's 37k. The 2nd hit is Adrian Holovaty's which
has a good link to Zrusilla's summary. Adrian: "Python as a saner
ruby..." Anyway,
anybody else found good substantive writeups? There's a lot of
bloggery reminding us that PHP is "evil",horrible, that projectors
don't work very easily. ONe blogger ran out of lead for his mechanical
pencil and couldn't take notes anymore...

http://www.livejournal.com/users/zrusilla/337117.html
http://lxer.com/module/newswire/lf/view/49281/
http://www.inkdroid.org/journal/2005/12/04/snakes-and-rubies/
http://www.loudthinking.com/arc/000545.html

The last is DHH, who started rails project, I can't spell his name.

 

[chuck]

I did a fairly thorough investigation of web frameworks that let us

write Python (we didn't care what the framework was written in; merely
that it interfaced with Python) for one of the systems I've built this
year. I wouldn't call the evaluation of web frameworks a problem - we
met our schedules, and the tool evaluation phase was by *far* the
shortest phase in the project, taking less than a week. Most of the
evaluations were easy - read the description of the framework, and
decide that we're working outside the problem space it's desinged
for. It certainly wasn't wasted time - I found a tool that I hadn't
heard of previously that was nearly perfectly suited to the job at
hand.

As I read through this thread I can't say that I disagree that having
more choices is a 'good thing'. However in your example here - I
suspect that you are a bit sharper and have a bit more guts than your
average code slinger since you appear to be an independent. You've got
to remember that your average corporate programmer - which are the
folks driving the popularity of programming languages - isn't that
sharp/confident. (I don't mean to insult anyone but that just the
facts.) They don't do things like evaluate frameworks and make smart
choices. This is why there needs to be obvious and singularly popular
frameworks and IDE's for Python so that people don't have to think that
hard about it. Take Java for example - for the most part its Eclipse
and Struts. I know there are many other choices (I've used them), but
even the managers know these terms. Very, very few people I know in
the IT world know of 'Python', let alone the name of any web framework
or an IDE for Python.

One of the great things about Python is its simplicty/clarity. Its a
shame that there doesn't also exist a clarity of choice for a web
framework for Python or an IDE for that matter. Both of these would go
a long way in motivating people to take a look at Python and realizing
what great value it has to offer the IT world in solving problems.

 

[A.M. Kuchling]

If you claim there's a web project that's unfeasible to do in Ruby,
you'd better come up with a strong example. If you're making no such
claim, which would be counter to the claims of the Ruby community, then
there aren't gonna be any web projects unfeasible with Rails, either.

I believe Rails assumes you're using a relational database, not an
object database like Durus or the ZODB. It seems to me Django is
similarly focused; are there hooks that would allow replacing an RDBMS
commit with a custom commit callback?

--amk

 

[Ben Sizer]

Well, they come in at least three major variants: complete publishing
system (ake zope), templating system (aka psp), and modules (aka
cgi). Each of these is focused on a different level of the problem,
and hence is suitable for different things.

I see what you mean, but unfortunately I think there is a lot more
fuzziness than that. If the separate parts were clearly delineated
things would be a lot better. I look to the Database API Specification
as a great example of how this could (should?) be done, allowing for
easy interchangeability while still providing a well-documented
standard, and the opportunity to bundle a basic module with the
standard library without raising the difficulty level for those who
wish to use other frameworks. A PyWebForm API and a PyWebSession API
would be fairly easy to create, for example. Templating maybe less so,
but not much.

Syntax can be very important, especially for templating
systems. Typically, those are used in situations where you have a lot
of X/HTML and want a bit of dynamic content. Ideally, you want to be
able to treat this just like a static HTML page. If the syntax of a
templating system makes your standard web tools puke, you probably
want to avoid it.

I think templating syntax is very important, but with something like
Python I think the future is in modules like HTMLTemplate rather than
the ASP/PHP model. When you're working with a valid XML page in the
first place, all your tools should work adequately.

 

[Alia Khouri]

In http://subway.python-hosting.com/ticket/216 Peter Mere writes:

"Subway has a lot of ideas TurboGears lacks. Everything from the
@client ajax-in-python to CherryFlow. On technical merits, Subway
should eat TurboGears' dinner.

But we all know market outcomes are not based on technical merit.
They're based on marketing. And as an open-source marketing project,
TurboGears is eating Subway's dinner. And not just those low-fat subs,
either - they're pouring it on thick!

It is a truism that python is the language with more web app frameworks
than keywords. Of this LaoTse wrote, "Conquest is a method of union.
The smaller submits to the larger to obtain custom. The larger submits
to the smaller to obtain service. If both would endure, both must
submit."

So it's time to stop trumpeting subway as "the best framework", and by
uniting with TurboGears definitively create the best web app framework.
The combination of the two would become an unstoppable juggernaut of
python mindshare, and all the rest of the frameworks would either
componentize or be dismissed as toys.

If Subway does not unite, chaos will continue in python web app land,
and ruby will become ascendant. This is more than a critical issue -
don't dismiss it without understanding that doing so will have severe
repercussions for subway (and by a process of horsshoe nail extraction,
the whole world!)"

All I can say is HEAR HEAR!!!!

AK

 

[gene tani]

In http://subway.python-hosting.com/ticket/216 Peter Mere writes:


"Conquest is a method of union. ....
unstoppable juggernaut of

chaos will continue in python web app land,
and ruby will become ascendant. This is more than a critical issue -
don't dismiss it without understanding that doing so will have severe
repercussions for subway (and by a process of horsshoe nail extraction,
the whole world!)"

All I can say is HEAR HEAR!!!!

AK

I feel like i'm being indoctrinated for a cult that won't let you eat
or go to the bathroom

 

[Mike Meyer]

As I read through this thread I can't say that I disagree that having
more choices is a 'good thing'. However in your example here - I
suspect that you are a bit sharper and have a bit more guts than your
average code slinger since you appear to be an independent. You've got
to remember that your average corporate programmer - which are the
folks driving the popularity of programming languages - isn't that
sharp/confident. (I don't mean to insult anyone but that just the
facts.) They don't do things like evaluate frameworks and make smart
choices.

Let's just note that sturgeon's law applies to all programmers, and
let it go at that. I'll get back to this.

And thank you.

One of the great things about Python is its simplicty/clarity. Its a
shame that there doesn't also exist a clarity of choice for a web
framework for Python or an IDE for that matter. Both of these would go
a long way in motivating people to take a look at Python and realizing
what great value it has to offer the IT world in solving problems.

I'm not a big fan of popularity for the sake of popularity. While
there's nothing wrong with popularity, and it does have it's
advantages, "it would make Python more popular" isn't an adequate
justification for a change, and *certainly* not for a change that is
otherwise undesirable. After all, sturgeon's law applies to the
populace, so "the populace's" skill at judging languages/IDEs/etc. is
debatable at best.

If having to many web frameworks is a real problem, let's work on
it. If not - well, we'll suffer with the consequences of using
high-quality, if obscure, tools.

And, to head off the obvious complaints, "not being designed by the
populate" does not imply "hard for the populace to use". With Lehrer's
comments on folk music in mind, I'd argue that the reverse implication
is more likely true.

<mike

 

[Mike Meyer]

I see what you mean, but unfortunately I think there is a lot more
fuzziness than that. If the separate parts were clearly delineated
things would be a lot better. I look to the Database API Specification
as a great example of how this could (should?) be done, allowing for
easy interchangeability while still providing a well-documented
standard

Constant queries on c.l.python for "Which DB module should I use"
would indicate that having a standard and to many choices isn't really
better than having no standard and to many choices.

and the opportunity to bundle a basic module with the standard
library without raising the difficulty level for those who wish to
use other frameworks.

Marking one web framework - or one DB module - as blessed would
certainly ease the problem. I don't have a problem with that, but I
don't build a Python distribution.

A PyWebForm API and a PyWebSession API
would be fairly easy to create, for example. Templating maybe less so,
but not much.

I'm not convinced these would be fairly easy to cerate. If you think
that's the case, please take a shot at it, as I think such a standard
would be a good thing.

<mike

 

[chuck]

Let's just note that sturgeon's law applies to all programmers, and

let it go at that. I'll get back to this.
fine

And thank you.

you are welcome

I'm not a big fan of popularity for the sake of popularity.

neither am I

"it would make Python more popular" isn't an adequate
justification for a change

I disagree. The world desperately needs programming languages,
frameworks, etc. that allow for the more efficient creation and
maintenance of software application - web or otherwise. I happen to
think that Python is something that could help. With this regard the
popularity of Python seems relevant to me.

and *certainly* not for a change that is
otherwise undesirable.

please explain

 

[Mike Meyer]

If Subway does not unite, chaos will continue in python web app land,
and ruby will become ascendant. This is more than a critical issue -
don't dismiss it without understanding that doing so will have severe
repercussions for subway (and by a process of horsshoe nail extraction,
the whole world!)"

Um - why should I switch to subway?

<mike

 

[Mike Meyer]

I disagree. The world desperately needs programming languages,
frameworks, etc. that allow for the more efficient creation and
maintenance of software application - web or otherwise. I happen to
think that Python is something that could help. With this regard the
popularity of Python seems relevant to me.

I think Python is popular enough that it's not going to
vanish. Once you've reached that point, further popularity doesn't
helop your cause.

please explain

It's conceivable that a change might make Python more popular and also
detract from the language in some way. For a ridiculous example,
making Python interpret Perl 6 would certainly make it more popular,
but I would argue that would seiously detract from the language.

<mike

 

[bonono]

It's conceivable that a change might make Python more popular and also
detract from the language in some way. For a ridiculous example,
making Python interpret Perl 6 would certainly make it more popular,
but I would argue that would seiously detract from the language.

why would one want python to interpret Perl 6 ?

 

[Mike Meyer]

why would one want python to interpret Perl 6 ?

So you could have a perl 6 interpreter, of course. Assuming you
wanted one, of course.

<mike

 

[floydophone]

I'm the founder and lead developer of Subway.

I am all for it. TG would have to change a couple of things IMHO, but I
think it would be a great idea.

If we were to merge projects, we would have to get a serious
TurbowaySubgears blogging hype train going.

- Peter Hunt