Which Python web framework is most like Ruby on Rails?

[John J. Lee]

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.
+100


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

Be big and use the 'TurboGears' name. It has good PR.

crackajax is *so* cool How is it coming along?


John

 

[floydophone]

I am looking for ways to improve CrackAJAX; I added for...in loops and
iterators, but it still needs work.

I would plan on sticking with the Turbogears name if we were to merge.
My real worries are the controller styles (functions vs classes) and
the templating language (Cheetah vs Kid). Those will be points of
conflict between the two projects, but I hope we would be able to solve
them.

Thoughts?

Pete

 

[Jan Niklas Fingerle]

My real worries are the controller styles (functions vs classes) and

You can wrap those quite easily, but ...

the templating language (Cheetah vs Kid). Those will be points of

.... how should the user base of one migrate to the other? I depend on
(as far as "depend" might go) the Kid funtionality (i.e. importing
ElementTree-s as sub-trees, and ElementTree is part of the heart of my
application logics).

conflict between the two projects, but I hope we would be able to solve
them.

Use Kid ;-) Well, no, make it easy to change templating engines,
whatever you ship as included engine.

Cheers,
--Jan Niklas

 

[Luis M. Gonzalez]

Sorry for the interruption, but...
Has anyone tried KARRIGELL??

I find hard to believe there is any easier python framework than this
one.
It's incredibly flexible, very fun, very powerful and with an almost
flat learning curve.

Go check it out (NOW!)
http://karrigell.sourceforge.net/

 

[Russell E. Owen]

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

I agree. It's sad to see such a terrible language as PHP so popular, and
such a complicated mess in python, my language of choice.

I love python and am lucky enough to be able to do almost all my coding
in it. Yet even I use PHP to serve a database. I loathe PHP, but:
- it came preinstalled on my system (MacOS X 10.3.x).
- I found a nice simple intro to it (a quickstart guide, which taught me
all I needed to know for my simple needs).
- I started out by looking at the choices in python. Of course. I read
the shootout. I asked for help. But the results were utterly
overwhelming.

I wanted (and I am guessing this isn't too far off for most users -- at
least most non-web-gurus) a framework that was:
- Well designed, robust, "finished" (i.e. not alpha).
- Easy to use, especially for simple, basic tasks. (And not a toy, of
course -- powerful enough to handle reasonable traffic and tasks.)
- Easy to install.
- Well documented, with a good introduction or tutorial.
- Likely to be around for awhile. The plethora of options on Python do
NOT inspire confidence in that area.

Some choice is good -- especially if the choices solve obviously
different problems. But too much choice is paralyzing and fragments the
community.

Anyway, thanks for holding this discussion. Django and TurboGears were
both new to me. I hope something finally gets popular enough to be worth
betting on.

-- Russell

 

[Russell E. Owen]

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.[/QUOTE]

I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python. Also, typically either:
- One stands out (because others have been abandoned or whatever), so
there's an easy answer, or
- They all work about the same, so even if you decide to switch for some
reason it makes little difference.

SQLObject breaks that mold, but for excellent reasons. It's nice to
start from a standard and then maybe somebody figures out a really nifty
way to do things. (I haven't used SQLObject yet, but I plan to try it
out when things calm down a bit).

If we had a standard basic web framework or a standard template language
it would really help (more folks using it, more folks who can help folks
learning it, better documentation, more focused development). Something
better might come along, and then it'd be easier to evaluate and more
appreciated.

-- Russell

 

[Paul Rubin]

I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python. Also, typically either:
- One stands out (because others have been abandoned or whatever), so
there's an easy answer, or

But none of them stand out, the way the ones in PHP stand out, by
being included in the standard library.

- They all work about the same, so even if you decide to switch for some
reason it makes little difference.

You should not even have to spend one millisecond of your attention
thinking about it then.

With Python's web template systems, there's a real set of distinct
ones and it's maybe still too early to say there's an easy answer.
Hopefully there will eventually be one.

With db modules, if there's an easy answer, then I can't understand
why that easy answer isn't incorporated into the stdlib so people can
stop having to research it. If there's no easy answer, then maybe the
dbapi standardization process hasn't worked so well after all.

 

[Benji York]

I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python.

Perhaps it's off-topic for this thread, but I think "picking a database"
is the first mistake most people make. It's a form of premature
optimization.

Just like any other component in a system, develop your app without a
database until you see that you need one, don't just assume you do from
the beginning.

I was listening to an interview with Ron Jeffries the other day, and
when asked what he considers one of his greatest accomplishments (as a
software developer), he told a story about working on a large
development project for a system that was going to process large amounts
of data.

At the beginning of the project he was asked what database they should
use, he said (something like) "wait until we need one". During
development several people asked what database they were going to use,
he reiterated: "wait until we need one". After the system went into
production (without a database) he eventually left the company. Years
later he found out that they still hadn't "chosen a database" because
they had yet to need one. Sounds like a pretty good application of
YAGNI to me. http://xp.c2.com/YouArentGonnaNeedIt.html

That's also why I don't see much point to the
relational-database-centric web frameworks that are all the rage today,
but I'll save that rant for another day.

 

[Mike Meyer]

Perhaps it's off-topic for this thread, but I think "picking a
database" is the first mistake most people make. It's a form of
premature optimization.

For lots of problems, that's true. But not for all of them.

Just like any other component in a system, develop your app without a
database until you see that you need one, don't just assume you do
from the beginning.

What makes me think "I need a database" is a requirement that says
"multiple simultaneous writers". Yes, it's possible to deal with the
data locking and the like on your own - but this tends to be
system-dependent, and hard to get right except in the simple
cases. It's also one of the things that databases are *really* good
at. In this case, using a database isn't a performance optimization,
it's a code simplification optimization, sort of like using
Queue.Queue to do threading.

That's also why I don't see much point to the
relational-database-centric web frameworks that are all the rage
today, but I'll save that rant for another day.

If your web clients can write data, then you've got multiple
simultaneous writers - which means you probably want a database. Of
course, people like to build web apps that don't write data on top of
relational databases, which I think are well deserving of your rant.

<mike

 

[Paul Rubin]

What makes me think "I need a database" is a requirement that says
"multiple simultaneous writers".

I'd go a little further and say "multiple simultaneous writers doing
multi-step transactions with steps that can have high latency",
e.g. transactions that have to wait for user input while the
transaction is in progress.

Yes, it's possible to deal with the data locking and the like on
your own - but this tends to be system-dependent, and hard to get
right except in the simple cases.

If the transactions are simple and low-latency, then it can be enough
to have a single process own the whole database, and have every client
send all its requests to the db process.

If your web clients can write data, then you've got multiple
simultaneous writers - which means you probably want a database. Of
course, people like to build web apps that don't write data on top of
relational databases, which I think are well deserving of your rant.

It's been a long-time source of puzzlement to me why so many web sites
are so slow, and RDBMS overhead is an obvious candidate. So the rant
seems appropriate even in the case of web apps where clients can cause
db updates.

 

[Paul Rubin]

If the transactions are simple and low-latency, then it can be enough
to have a single process own the whole database, and have every client
send all its requests to the db process.

Meant to say: it can be enough to let the clients lock the database,
do their thing quickly, and release the lock. What I described is of
course how it's usually done with SQL. Sigh. Other approaches
include running the whole app in one process (asyncore/twisted),
having a multi-threaded app where one thread owns the db and
serializes requests through Queues, etc.

 

[Dave Benjamin]

But none of them stand out, the way the ones in PHP stand out, by
being included in the standard library.

Well, even with PHP there are several ways to talk to a given database,
and the library du jour has changed a few times. When I first learned PHP,
it was pretty standard to use the mysql_* functions (and for another
database, a set of functions specific to that database). Then, PEAR DB
came out, which wrapped around these functions and provided some database
abstraction for portability. This is the direction I went, but I don't
know many others that followed.

PEAR is distributed with PHP, so it's basically standard, but in the early
days it wasn't in the library path by default so it didn't stick out as
the obvious way to talk to a database. Also, ADOdb was around at the time,
which was (and still is) a pretty popular third-party interface -- maybe
more popular than PEAR DB. And now there's the new "mysqli" interface,
which is yet another (this time object-oriented) alternative to the
mysql_* functions, but once again tied specifically to MySQL.

So, PHP has had the same kind of problems, even with database functions in
the core. There's more than one way to do it, even with standard
functions. Same with Java -- should we use the native Type 3 driver or the
pure-Java Type 4 driver? Scrap JDBC and go with JDO or EJB? Hibernate?

I'm not saying it's necessarily a good thing to have all these options,
but it's not atypical, especially considering how many database users are
out there and how different their needs are. In the Java world, commercial
vendors actually compete to produce better JDBC driver implementations,
which increases the number of options even more but results in some
wickedly fast and advanced drivers.

I do agree that the "obsolete" MySQLdb page needs a makeover, or to be
removed entirely. Also, getting psycopg to install on Windows involves
hunting around for some magic installers, and I'm afraid to delete them
off of my hard drive because I'm not sure I'll be able to find them again.
Perhaps all that is needed is some better organization.

Dave

 

[Scott David Daniels]

For lots of problems, that's true. But not for all of them.

If the data you store and update is sufficiently valuable to your
enterprise, picking a database may be vital. Transactions guarantee
every update either happens or not, and infrastructure is provided
for you to be able to backup and restore the data you've obtained.
If you don't get transaction guarantees, your applications will have
to deal with all kinds of inconsistent data (either by ignoring the
problem or guessing the best answer).

--Scott David Daniels
(e-mail address removed)

 

[Alex Martelli]

If the data you store and update is sufficiently valuable to your
enterprise, picking a database may be vital. Transactions guarantee
every update either happens or not, and infrastructure is provided
for you to be able to backup and restore the data you've obtained.

A good point, but there are others. If the data is valuable, there WILL
be requests from parts of the enterprise to use that data in other ways
that were originally not anticipated. If you keep the data in a
relational DB with any kind of sensible schema, then the data IS
reusable, including in impromptu exploratory ways from interactive
prompts of many kinds -- you don't necessarily need "programmers" to
enable such reuse.

Picking ONE database engine may well be premature nevertheless --
perhaps the small amounts of data you have today make SQLite ideal, but
tomorrow there will be many more data, and you'll want PostgreSQL, or
whatever; which is why maintaining portability among different databases
may well be a great choice, even when it requires the overhead of a
"database independence layer". But being able to rely on a relational
underlying model remains an excellent idea in many cases, even when
minute details of SQL dialects &c require such a layer...


Alex

 

[Scott David Daniels]

A good point, but there are others. If the data is valuable, there WILL
be requests from parts of the enterprise to use that data in other ways
that were originally not anticipated. If you keep the data in a
relational DB with any kind of sensible schema, then the data IS
reusable, including in impromptu exploratory ways from interactive
prompts of many kinds -- you don't necessarily need "programmers" to
enable such reuse.

We are in violent agreement here. My contention is that you need a
_real_ relational database here, not that you need to pick a vendor.
MySQL vs. Pick vs. ... should be shut out early. A truly relational DB
has value, picking a particular one early does not. The attributes I
describe are available from any reputable relational DB vendor, and make
no mistake, PostgreSQL is what I consider a vendor -- a provider of a
fully thought-out and implemented solution.

> ... maintaining portability among different databases may well be a
> great choice, even when it requires the overhead of a "database
> independence layer".

Yup. I think you should choose a vendor, but not in the sense of buying
lock-in; in the sense of accepting a data model.

--Scott David Daniels
(e-mail address removed)

 

[Ben Sizer]

But none of them stand out, the way the ones in PHP stand out, by
being included in the standard library.

I think that's a very good reason to include them in the standard
library.

With Python's web template systems, there's a real set of distinct
ones and it's maybe still too early to say there's an easy answer.
Hopefully there will eventually be one.

I think we're talking very small values of 'distinct' here. Arguably
the biggest difference between ASP and PHP is the language, then the
libraries and objects you use. Python already has a separate language
and libraries - does it really need a multitude of syntaxes for
embedding it in HTML? Obviously some people think so, but I wonder if
this isn't just because of the ease with which an enterprising web
developer can roll their own and release it, rather than there being
any significant benefits to any individual package over the others.

With db modules, if there's an easy answer, then I can't understand
why that easy answer isn't incorporated into the stdlib so people can
stop having to research it.

I think there's an easy answer in most cases. Who is responsible for
making the decision though?

 

[Paul Boddie]

It's been a long-time source of puzzlement to me why so many web sites
are so slow, and RDBMS overhead is an obvious candidate. So the rant
seems appropriate even in the case of web apps where clients can cause
db updates.

Indeed. Large portions of a lot of Web sites could actually be deployed
statically, rather than hitting a database several times a page to
retrieve stuff which changes once in a blue moon. Moreover, static page
hosting is generally a lot cheaper than dynamic program hosting.

On the subject of requiring an RDBMS, though, whilst there are various
kinds of applications which benefit overwhelmingly from using such a
system, my experience with Web frameworks that have such prerequisites
suggests that new users either have to slog through the setup process
and take it on trust that installing and/or configuring an RDBMS is a
good and necessary thing, or they question the relevance of having to
set such a thing up.

Certainly, for general Web programming, every time I see some Web
framework which just ploughs straight forward with the "and now you'll
need to set up MySQL" catchphrase for "our simple Wiki application", I
can't help feeling that today's letters are W, T and F.

Paul

 

[paron]

Wow! You´re right, at least at first reading. It looks REALLY simple,
and almost anything you can dream up will work. Python scripts,
python-in-html, html-in-python, and "karrigell services" ( based on
CherryPy). Seems to support smart urls, sessions, authentication, and
internationalization out-of-the-box. Documentation seems clean, short,
and to the point.

Has anyone other than Kerrigell himself used it? I think I will use it
around the shop for a desktop project just to get the feel of it. I am
not sure about the Gadfly db -- fine as a default for development; but
I'd need other options for production.

My answer to the perennial Python newbie question, "What do I use for a
GUI (please-please-please-I-hope NOT Tkinter or any derivative
thereof)?" may change to, "Just say 'Kerrigell' and do it in the
browser."

Ron

 

[paron]

Oops! Second line on the home page:

<snip>With Karrigell you have

. . .
* a pure-Python database engine : KirbyBase

Karrigell can also work with . . . all the databases for which a Python
API exists (sqlite, mySql, PostGreSQL, ZODB, etc). </snip>

Well, off to reread and work the tut! My apologies!

Ron

 

[Luis M. Gonzalez]

Karrigell can also work with . . . all the databases for which a Python

API exists (sqlite, mySql, PostGreSQL, ZODB, etc). </snip>

Well, that's exactly what makes KARRIGELL so especial.
It is very flexible and lets you use whatever database or component you
want. It doesn't force you to use an specific package for each task.
It doesn't force you either to learn and use any templating language
(you don't need it!), although you can do it if you want.

The traditional "Hello world" page, can be coded like this:

print "Hello World"

No boilerplate code, no need to write a class or to fidle with strange
configurations.
It's simply python!
The only problem with KARRIGELL, I guess, is that its creator is very
humble and doesn't like to advertise his creature. He is not very fond
of "marketing" ...
This is too bad because I feel that other frameworks are getting a lot
of the attention that Karrigells deserve...

Luis