Which Python web framework is most like Ruby on Rails?

[seberino]

I'm interested in knowing which Python web framework is most like Ruby
on Rails.

I've heard of Subway and Django.
Are there other Rails clones in Python land I don't know about?

Which one has largest community/buzz about it?
Chris

[Jorge Godoy]

"se******@spawar.navy.mil" <se******@spawar.navy.mil> writes:

Are there other Rails clones in Python land I don't know about?

Which one has largest community/buzz about it?

http://www.turbogears.com ;-)

--
Jorge Godoy <go***@ieee.org>

[bonono]

I like TurboGears best(haven't used any of those you mentioned, just a
brief browse and don't like any of them) and it has a very helpful
community.

se******@spawar.navy.mil wrote:

I'm interested in knowing which Python web framework is most like Ruby
on Rails.

I've heard of Subway and Django.
Are there other Rails clones in Python land I don't know about?

Which one has largest community/buzz about it?
Chris

[gene tani]

se******@spawar.navy.mil wrote:

I'm interested in knowing which Python web framework is most like Ruby
on Rails.

I've heard of Subway and Django.
Are there other Rails clones in Python land I don't know about?

Which one has largest community/buzz about it?
Chris

Subway and Django are *exactly* like rails, and they have buzz. And
have you looked at slashdot codebase?

Seriously, these frameworks are broad and deep, write more about your
app, platform, databases and DBMS and you'll get a better anwer, e.g.
you like has_and_blongs_to_many, you want an ActiveRecord clone, or you
like the naming defaults in rails' scaffolding, you like the DSL
quality of the rails code, ...

[seberino]

Gene

Thanks for your kind email. I am a newbie web developer that just was
hoping
*any* framework was bubbling to surface to standout amongst all the
rest.
I don't know /why/ Rails is getting buzz. I've just heard some good
things
about it but don't want to switch to Ruby.

My main goal is to support any framework that looks like it has a
chance
of taking over the marketspace Rails is competing in. Hence, I want
to avoid any "also rans" aka "Yet Another Python Web Framework".

Chris

[gene tani]

se******@spawar.navy.mil wrote:

Gene

Thanks for your kind email. I am a newbie web developer that just was
hoping
*any* framework was bubbling to surface to standout amongst all the
rest.
I don't know /why/ Rails is getting buzz. I've just heard some good
things
about it but don't want to switch to Ruby.

My main goal is to support any framework that looks like it has a
chance
of taking over the marketspace Rails is competing in. Hence, I want
to avoid any "also rans" aka "Yet Another Python Web Framework".

Chris

I realized the first line of my post was pretty evil. *Don't* look at
the slashdot (200+k lines of perl). What i suggested to a friend who
recently asked the same thing is to pull up tags like "rails python" in
del.icious, furl and digg, see what other people like. That's a pretty
good way to measure buzz, actually. (My friend chose PHP, even tho i
told him he'd have unmaintainable, easily defaced code.)

[seberino]

Django might be the answer.

[Dody Suria Wijaya]

Django is the closest one.

se******@spawar.navy.mil wrote:

I'm interested in knowing which Python web framework is most like Ruby
on Rails.

I've heard of Subway and Django.
Are there other Rails clones in Python land I don't know about?

Which one has largest community/buzz about it?
Chris

[Alex Martelli]

gene tani <ge*******@gmail.com> wrote:
...

the slashdot (200+k lines of perl). What i suggested to a friend who
recently asked the same thing is to pull up tags like "rails python" in
del.icious, furl and digg, see what other people like. That's a pretty
good way to measure buzz, actually. (My friend chose PHP, even tho i

Alternatively, counting Google hits:

rails python django 112,000
rails python subway 81,600
rails python turbogears 32,000

This isn't exactly "buzz", of course, but it's SOME measure of "critical
mass" -- and with django about equal to subway+turbogears, it does not
appear to show any emerging dominance. A significant measure of "buzz"
might be obtained by redoing the same search in, say, two weeks, and
noticing the deltas...
Alex

[Luis M. Gonzalez]

As fas as I know, TurboGears is not very different.
But it is a project that unifies many different third party components
into one integrated package.
Its main component is CherryPy, which is a known python web framework.

[DH]

Alex Martelli wrote:

Alternatively, counting Google hits:

rails python django 112,000
rails python subway 81,600
rails python turbogears 32,000

This isn't exactly "buzz", of course, but it's SOME measure of "critical
mass" -- and with django about equal to subway+turbogears, it does not
appear to show any emerging dominance. A significant measure of "buzz"
might be obtained by redoing the same search in, say, two weeks, and
noticing the deltas...

Actually the turbogears mailing list has ~850 subscribers while
the django one has ~650. I don't think that should be interpreted
as anything, but it does show the opposite of what you found with
the google search. They both have "buzz".
Also others are working on another rails-like framework
called pylons: http://pylons.groovie.org/project
Because of course if other languages have 1 or two frameworks, python
needs a dozen.

[gene tani]

DH wrote:

Alex Martelli wrote: Because of course if other languages have 1 or two frameworks, python
needs a dozen.

["there are still fewer %s than py keywords"%x for x in ["IDEs","web
app frameworks","GUI frameworks"]]

and 37000 google hits for "Snakes and Rubies"?!

[Mike Meyer]

[Not sure if this attribution is correct.]

Alex Martelli wrote:
Because of course if other languages have 1 or two frameworks, python
needs a dozen.

People keep talking about Python's wealth of web frameworks as if it
were a bad thing. I just don't see it. Just like I like to have more
than 1 or 2 languages available for programming, I like to have more
than 1 or 2 web frameworks available for building web sites. That I
can get the flexibility I want in this area *without* having to
abandon Python is a plus for Python.

Or are the web frameworks for the languages with an impoverished
selection really that flexible? Is Ruby on Rail, for instance, really
going to do the things that Zope does well almost as well as Zope does
them, and the things that Cheetah does well almost as well as Cheetah
does them, and the things that web.py does well almost as well as
web.py does them? If that's the case, the complaint isn't "Python has
to many web frameworks", it's "Python doesn't have a good web
framework."

Thanks,
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Ben Sizer]

Mike Meyer wrote:

[Not sure if this attribution is correct.]

Alex Martelli wrote:
Because of course if other languages have 1 or two frameworks, python
needs a dozen.

People keep talking about Python's wealth of web frameworks as if it
were a bad thing. I just don't see it. Just like I like to have more
than 1 or 2 languages available for programming, I like to have more
than 1 or 2 web frameworks available for building web sites. That I
can get the flexibility I want in this area *without* having to
abandon Python is a plus for Python.

Flexibility is good, but personally I think the problem is that instead
of useful variety, we have redundant overlap. How many different
templating systems, sql<-->object mappings, and URL dispatch schemes do
we need? And what exactly is the difference between them all, except
for slightly different syntax?

One major benefit of reducing the number of such frameworks is that a
larger community would form around each product, meaning better
documentation and examples. Also, it would be easier to know which one
to recommend for a given task, when there are fewer available and they
are more distinct. In particular, it would be helpful to have something
simple in the standard library, as currently there's a large barrier to
entry for the Python newbie who wants to get into web programming,
compared to ASP or PHP, or even Java servlets.

--
Ben Sizer

[gene tani]

Ben Sizer wrote:

Mike Meyer wrote:

[Not sure if this attribution is correct.]

Alex Martelli wrote:
Because of course if other languages have 1 or two frameworks, python
needs a dozen.

woops, that attribution is absolutely *wrong*, DH said that, sorry Alex

[gene tani]

Ben Sizer wrote:

Mike Meyer wrote:

[Not sure if this attribution is correct.]

Alex Martelli wrote:
Because of course if other languages have 1 or two frameworks, python
needs a dozen.

People keep talking about Python's wealth of web frameworks as if it
were a bad thing. I just don't see it. Just like I like to have more
than 1 or 2 languages available for programming, I like to have more
than 1 or 2 web frameworks available for building web sites. That I
can get the flexibility I want in this area *without* having to
abandon Python is a plus for Python.

Flexibility is good, but personally I think the problem is that instead
of useful variety, we have redundant overlap. How many different
templating systems, sql<-->object mappings, and URL dispatch schemes do
we need? And what exactly is the difference between them all, except
for slightly different syntax?

One major benefit of reducing the number of such frameworks is that a
larger community would form around each product, meaning better
documentation and examples. Also, it would be easier to know which one
to recommend for a given task, when there are fewer available and they
are more distinct. In particular, it would be helpful to have something
simple in the standard library, as currently there's a large barrier to
entry for the Python newbie who wants to get into web programming,
compared to ASP or PHP, or even Java servlets.

--
Ben Sizer

as to the actual substance of this thread, i searched and couldn't find
the number of committers for rails, django, zope, subway etc, anybody
know?

[Alex Martelli]

gene tani <ge*******@gmail.com> wrote:

Ben Sizer wrote:

Mike Meyer wrote:

[Not sure if this attribution is correct.]
> Alex Martelli wrote:
> Because of course if other languages have 1 or two frameworks, python
> needs a dozen.

woops, that attribution is absolutely *wrong*, DH said that, sorry Alex

NP, I noticed but decided not to comment, particularly since I roughly
agree with the spirit of DH's comment. Graham and Norvig, among others,
have often argued that there are parallels between Lisp and Python; the
proliferation of frameworks for a given task, I think, is one of them.
Good thing we have more things "nailed down" in the standard library...
but even then, e.g. with asyncore vs Twisted, there's no holding down a
different [here, better] implementation of similar ideas from emerging
as a third-party framework, anyway.
Alex

[Mike Meyer]

"Ben Sizer" <ky*****@gmail.com> writes:

Mike Meyer wrote:

[Not sure if this attribution is correct.]
And it was apparently wrong. Apologies to both DH and AM.

> Alex Martelli wrote:
> Because of course if other languages have 1 or two frameworks, python
> needs a dozen.

People keep talking about Python's wealth of web frameworks as if it
were a bad thing. I just don't see it. Just like I like to have more
than 1 or 2 languages available for programming, I like to have more
than 1 or 2 web frameworks available for building web sites. That I
can get the flexibility I want in this area *without* having to
abandon Python is a plus for Python.

Flexibility is good, but personally I think the problem is that instead
of useful variety, we have redundant overlap. How many different
templating systems, sql<-->object mappings, and URL dispatch schemes do
we need? And what exactly is the difference between them all, except
for slightly different syntax?

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.

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.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[chuck]

> People keep talking about Python's wealth of web frameworks as if it

were a bad thing.

I disagree somewhat. While variety and choice are nice, sometimes
having too many choices may inhibit people from trying the language
because they don't know where to start in terms of framworks. Maybe
I'm wrong but if there is an element of truth what I suggest then that
would be a terrible shame since Python is such a great language.
Python's popularity might improve if there were a bit more unity within
the Python community with regards to (web) frameworks.

[Alex Martelli]

chuck <cm******@gmail.com> wrote:

People keep talking about Python's wealth of web frameworks as if it
were a bad thing.

I disagree somewhat. While variety and choice are nice, sometimes
having too many choices may inhibit people from trying the language
because they don't know where to start in terms of framworks. Maybe
I'm wrong but if there is an element of truth what I suggest then that
would be a terrible shame since Python is such a great language.
Python's popularity might improve if there were a bit more unity within
the Python community with regards to (web) frameworks.

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

[Robert Kern]

Alex Martelli wrote:

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
ro*********@gmail.com

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

[Alex Martelli]

Robert Kern <ro*********@gmail.com> wrote:
...

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]

al***@mail.comcast.net (Alex Martelli) writes:

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]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

al***@mail.comcast.net (Alex Martelli) writes:

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.

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]

Alex Martelli wrote:

Robert Kern <ro*********@gmail.com> wrote:
...

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.

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
ro*********@gmail.com

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

[Mike Meyer]

al***@mail.comcast.net (Alex Martelli) writes:

Robert Kern <ro*********@gmail.com> wrote:
...

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.

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[gene tani]

Robert Kern wrote:

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

On Thu, 15 Dec 2005 20:15:17 -0800,
Alex Martelli <al***@mail.comcast.net> wrote:

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]

Mike Meyer wrote:

"Ben Sizer" <ky*****@gmail.com> writes:

Flexibility is good, but personally I think the problem is that instead
of useful variety, we have redundant overlap. How many different
templating systems, sql<-->object mappings, and URL dispatch schemes do
we need? And what exactly is the difference between them all, except
for slightly different syntax?
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.

--
Ben Sizer

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

Alia Khouri wrote:

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]

"chuck" <cm******@gmail.com> writes:

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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

"Ben Sizer" <ky*****@gmail.com> writes:

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

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

"Alia Khouri" <al*********@yahoo.com> writes:

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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

"chuck" <cm******@gmail.com> writes:

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

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.

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

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[bonono]

Mike Meyer wrote:

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]

bo****@gmail.com writes:

Mike Meyer wrote:

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 ?

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

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[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

[John J. Lee]

fl*********@gmail.com writes:

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]

fl*********@gmail.com wrote:

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]

In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

al***@mail.comcast.net (Alex Martelli) writes:

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.

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]

In article <86************@bhuda.mired.org>, Mike Meyer <mw*@mired.org>
wrote:

"Ben Sizer" <ky*****@gmail.com> writes:

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.

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]

"Russell E. Owen" <ro***@cesmail.net> writes:

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]

Russell E. Owen wrote:

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

[Mike Meyer]

Benji York <be***@benjiyork.com> writes:

Russell E. Owen wrote:

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.

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Paul Rubin]

Mike Meyer <mw*@mired.org> writes:

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.