469,361 Members | 2,291 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,361 developers. It's quick & easy.

Which Python web framework is most like Ruby on Rails?

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

Dec 13 '05
122 7202
Pierre Quentel wrote:
I am Karrigell's author. I have chosen the GPL licence almost at random
(I saw that the Python licence was GPL-compatible), so I don't mind
switching to another Open Source licence if the GPL is liable to cause
problems. Which one would you advice : BSD ? Python licence ? another ?


see the section "Which open source license should I use?" on this page
for some solid advice, from a Python perspective:

http://wiki.python.org/moin/PythonSo...tionLicenseFaq

</F>

Dec 21 '05 #101
Alex Martelli wrote:
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

Richie Hindle <ri****@entrian.com> writes:
A good solution would be multiple-licensing. You state that the
code is (for example) triple-licensed under the GPL, LGPL and BSD
licenses. The user of your code decides which license to obey.
It's no more work for you, and you can please almost everyone (the
only people you won't please are those who believe that there is One
True License, and frankly you should ignore them - it's your code).


That's silly, you might as well just use BSD instead of triple
licensing like that.


You're pointing out yourself, a few lines lower, while this isn't so:
Another downside to BSD is that it becomes impermissible to improve
Karrigell by transplanting GPL code into it from other programs. Yet


...which obviously is not a problem if K is available under either GPL
or BSD at the user's choice: anybody wanting to transplant GPL code into
it will pick the GPL side of the dual-licensing (I don't see any further
advantage in adding LGPL to the mix, maybe I'm missing s/thing...).


If K were to be dual licensed GPL/BSD, Pierre could not take some GPLed third
party code, incorporate it into K, and distribute K+3rdparty under both
licenses. 3rdparty would always be under the GPL, and the GPL conditions would
apply to the combination as a whole. That's the scenario Paul is referring to.

Of course, someone who is not Pierre who wants to distribute a web app with K
and some third party GPL module can do so just as well if K is only BSD-licensed
since BSD is compatible with the GPL. Dual licensing would only be necessary if
the alternative licenses were incompatible, e.g. Artistic/GPL like Perl or
MPL/GPL like Mozilla.

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

Dec 21 '05 #102
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> "Kent" == Kent Johnson <ke**@kentsjohnson.com> writes:

Kent> In the text you quoted I said, "a small in-house project that
Kent> might possibly be distributed to business partners or become a
Kent> product some day." Sounds like distribution to me.

My bad. I somehow managed to miss that.

Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkOplbwACgkQYu1fMmOQldXsSwCg0TRh98gcr+ 0xzhN4mKFCq3y8
SScAoICVaFIStF6PWfo+DZKo/v+WRicc
=69ov
-----END PGP SIGNATURE-----
Dec 21 '05 #103
(Responding to several posts)

"Ben Sizer" <ky*****@gmail.com> writes:
I don't see that. The web app gets run by Karrigell like a CGI script
is run by Apache, like a Linux app is run by the Linux kernel.
The web app uses parts of Karrigell though - things like the QUERY
variable or or Session object. That is analogous to linking with
Karrigell as a library....

"What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide.[...] If modules are
designed to run linked together in a shared address space, that almost
surely means combining them into one program.
Hmmm. I seem to remember RMS saying that the GPL didn't extend to
Emacs Lisp functions that the user writes, even though those call
various built-in Emacs functions, as long as they use the documented
API. Those certainly run in the same address space as Emacs. This is
the closest thing I can think of to the Karrigell situation.

[Alex Martelli re triple-licensing BSD/GPL/LPGL]
That's silly, you might as well just use BSD instead of triple
licensing like that.
You're pointing out yourself, a few lines lower, while this isn't so:
Another downside to BSD is that it becomes impermissible to improve
Karrigell by transplanting GPL code into it from other programs. Yet


...which obviously is not a problem if K is available under either
GPL or BSD at the user's choice: anybody wanting to transplant GPL
code into it will pick the GPL side of the dual-licensing (I don't
see any further advantage in adding LGPL to the mix, maybe I'm
missing s/thing...).

The resulting combined program could be distributed only under the
GPL, not the BSD license. A single-licensed BSD app already allows
distributing modified versions under the GPL (or even proprietary).

[Kent Johnson]

You may be right, I honestly don't know. Would your interpretation
change if I wanted to distribute an app built with py2exe that bundles
Karrigell and my code?

I'm not sure exactly how py2exe works. If it's basically just a
self-extracting archive, it doesn't sound like a problem, it's like
many distros that include the Linux kernel plus some applications.
(Although, I have to say, I've never really liked that practice and am
not sure why it's allowed, but it's done all the time). If it's a
more complex integration, you may need to make two separate
installers, where the first one would install Python and Karrigell,
and the second one would add your application files. There are
various technical advantages to that anyway (makes it easier to
incrementally upgrade your application, etc).

You may be right, I don't know. In the case of CherryPy, my code is a
bit more intimate with CP than a CGI is with Apache - I import CP
modules, subclass CP classes and make calls to CP functions from my
code. My guess is a Karrigell-based server would be similar.

OK, I'm no longer so terribly confident that there isn't a problem.
Again though, I see this as similar to the Emacs Lisp situation. I
wonder if that Emacs Lisp situation is considered a GPL exception. I
might ask RMS about this sometime.

GNU Classpath has an explicit exception:

http://www.gnu.org/software/classpath/license.html

but I'd think that would prevent merging parts of (say) GCC into GNU
Classpath.

Where would you draw the line? Suppose I want to use a GPLed library
in my Python code, does that mean I have to distribute my code under
the GPL if I distribute them together?

Yes, that's the point of using the GPL on a library instead of the
LGPL. So the Emacs example, if it doesn't rely on an exception, must
rely on the notion that Emacs isn't a library.
Dec 21 '05 #104
Just to add some more confusion to the discussion, here is what I've
found about other web frameworks :
CherryPy : BSD
Django : BSD
Jonpy : Python licence
Quixote : CNRI
Skunkweb : GPL or BSD
Snakelets : MIT
Subway : ? + licence of the components
PythonWeb : LGPL (will consider BSD-Style or Python if LGPL is a
problem)
Turbogears : MIT + licence of the components
Twisted : LGPL
Webware : Python licence
Zope : ZPL (Zope Public Licence)

There doesn't seem to be an obvious choice, but the GPL isn't used much
here

Regards,
Pierre

Dec 21 '05 #105
Paul Rubin wrote:
[Kent Johnson]
Where would you draw the line? Suppose I want to use a GPLed library
in my Python code, does that mean I have to distribute my code under
the GPL if I distribute them together?

Yes, that's the point of using the GPL on a library instead of the
LGPL. So the Emacs example, if it doesn't rely on an exception, must
rely on the notion that Emacs isn't a library.


It's not clear to me how my use of CherryPy as a web app framework is different, from the
point of view of the GPL, from how I might use something that we both would call a
library. From the client code it is pretty similar. In both cases I might import modules,
instantiate and subclass classes and call functions and methods from the library. If there
is a difference it seems the GPL is relying on pretty subtle distinctions to determine
whether my code is a "work based on the Program."

Kent
Dec 22 '05 #106

[Paul]
The web app gets run by Karrigell like a CGI script
is run by Apache, like a Linux app is run by the Linux kernel.


Paul, you keep making comparisons between Python web frameworks and the
Linux kernel. Are you aware that there is a special note attached to the
Linux GPL[1] explaining that user-space code is not considered a derived
work of the Linux kernel? Without that note, user-space code *could* be
considered a derived work of the kernel (obviously, or Linus Torvalds would
not have included the note). Unless a GPL web framework carries a similar
notice, the comparison doesn't hold up.

[1] http://www.linux-m32r.org/lxr/http/source/COPYING

--
Richie Hindle
ri****@entrian.com
Dec 22 '05 #107
Richie Hindle <ri****@entrian.com> writes:
Paul, you keep making comparisons between Python web frameworks and the
Linux kernel. Are you aware that there is a special note attached to the
Linux GPL[1] explaining that user-space code is not considered a derived
work of the Linux kernel? Without that note, user-space code *could* be
considered a derived work of the kernel (obviously, or Linus Torvalds would
not have included the note).


I don't think that note is part of the license. It just clarifies
what's already inherent, since probably a lot of people asked. If the
note were really necessary, then the license would not be GPL, it
would be "GPL plus note". In that case it would be impermissible to
insert any strict-GPL code into the kernel and distribute it. Since
there is such code in the kernel (FSF code even), I think there's no
problem even without the note.
Dec 22 '05 #108
On 20 Dec 2005 15:05:15 -0800,
Michael Tobis <mt****@gmail.com> wrote:
Python people don't really think that way. As a community we really
seem to inherit the open source dysfunction of trying harder to impress
each other than to reach out to the rest of the world. The problem is


Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.

--amk
Dec 22 '05 #109
On 22/12/05, A.M. Kuchling <am*@amk.ca> wrote:
On 20 Dec 2005 15:05:15 -0800,
Michael Tobis <mt****@gmail.com> wrote:
Python people don't really think that way. As a community we really
seem to inherit the open source dysfunction of trying harder to impress
each other than to reach out to the rest of the world. The problem is


Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.


A good start would be for there to be a way for newbies to get heard
more easily.

Newbies were all quite recently nonPythonPeople, and as such have some
very valuable insights into what it is like being a normal,
nonPythonPerson.

They normally get told they aren't pythonic yet, or that they should
write a PEP, or some such.

Ed
Dec 22 '05 #110
On Thu, 22 Dec 2005 14:05:08 +0000,
Ed Singleton <si*********@gmail.com> wrote:
Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.


A good start would be for there to be a way for newbies to get heard
more easily.


I don't see the connection between "Python users talk too much to
other Python users" and "newbies don't get heard".

--amk
Dec 22 '05 #111
On 22/12/05, A.M. Kuchling <am*@amk.ca> wrote:
On Thu, 22 Dec 2005 14:05:08 +0000,
Ed Singleton <si*********@gmail.com> wrote:
Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.


A good start would be for there to be a way for newbies to get heard
more easily.


I don't see the connection between "Python users talk too much to
other Python users" and "newbies don't get heard".


I wasn't particularly saying that there was a direct connection. You
said you had been worrying about the problem of Python suffering from
the "open source dysfunction" and had no idea how to fix it. I was
suggesting one of the main ways of fixing it.

In a little greater depth:

Open source suffers from insularity because the community places a
huge emphasis on reputation. Reputation is necessarily built-up over
time and once people have reputation they tend to forget what it is
like to not have it. (Additionally the type of person required to
expend that much effort in building up reputation tends not to spend
much time doing other, more "normal" things).

Thus the people who are listened to the most in any OSS community are
those who tend to know less about what it is like completely outside
of the OSS world.

These people tend to naturally gather to talk to each other, and they
tend to stratify themselves, generally paying good attention to those
above them and (in better communities like this one) those on the same
level and just below.

This leads to them insulating themselves even more from "reaching out
to the real world".

Luckily there is a large group of people who are involved in the
community but have recently been participating in the real world.
They have a strong understanding of what needs to be done to "reach
out to the real world", because they themselves have just recently
been reached out to.

They are the newbs.

Ed

PS If you don't know how to reach out to the real world, then by
definition you are not listening to newbs.

PPS Some cool sayings about newbs:

"The newbs shall inherit the earth"

"The future's bright; the future's newb"

"We don't inherit the OSS community from it's leaders; we merely
borrow it from the newbs"
Dec 22 '05 #112
A.M. Kuchling wrote:
On 20 Dec 2005 15:05:15 -0800,
Michael Tobis <mt****@gmail.com> wrote:
Python people don't really think that way. As a community we really
seem to inherit the open source dysfunction of trying harder to impress
each other than to reach out to the rest of the world. The problem is

Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.


I've talked to plenty of non-Python people about Python. The hard part for me is getting
them to believe me enough to try Python for themselves.

Kent
Dec 22 '05 #113
+1 for Kid -- it's more pythonic IMHO.

Dec 22 '05 #114
Kent Johnson wrote:
Luis M. Gonzalez wrote:

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

From my point of view the biggest problem with Karrigell is that it is released under the
GPL. Most of my projects at least have the potential of being distributed to customers and
GPL is not an option.

I don't understand your issue, as it applies to Python programs.

The GPL would (a) require you to supply the source to your customers,
and (b) allow them
to pass it on to others. But since Python programs are delivered as
source (.py files), or easily
decompiled bytecode (.pyc file), they have the source anyway, as well as
the static HTML
files for your app.

Python doesn't have a secure binary-only distribution format, so the
question of protecting
your IP via an obscurement mechanism is moot.

And using a BSD-like license doesn't help since they still have the
source in Python, and
BSD allows them to redistribute that.

Your only solution would be a proprietary license that states you
purchased this program
and don't have the right to pass it on to others, similar to ActiveState
or somesuch.

The real hook would seem to be the social one that you provide support
and improvements
so they need to keep you in business.

-Jeff

Dec 23 '05 #115
Jeff Rush <je**@taupro.com> writes:
Your only solution would be a proprietary license that states you
purchased this program and don't have the right to pass it on to
others, similar to ActiveState or somesuch.


It sounds like that's what Kent wants to do with the apps that he's
building. That's not permitted under the GPL, if the apps contain or
are based on GPL code. What's not totally clear is whether that
affects Karrigell apps (apps that run under Karrigell and call
Karrigell functions but don't modify Karrigell itself).
Dec 23 '05 #116
Paul Rubin wrote:
Jeff Rush <je**@taupro.com> writes:
Your only solution would be a proprietary license that states you
purchased this program and don't have the right to pass it on to
others, similar to ActiveState or somesuch.


It sounds like that's what Kent wants to do with the apps that he's
building. That's not permitted under the GPL, if the apps contain or
are based on GPL code. What's not totally clear is whether that
affects Karrigell apps (apps that run under Karrigell and call
Karrigell functions but don't modify Karrigell itself).


I believe that it's the FSF's view that importing a GPLed module triggers the
GPL conditions in analogy with dynamic linking for C and other such languages
(presuming the code is being distributed at all). I think it's reasonably safe
to say that most authors who choose the GPL deliberately also assume the FSF's
interpretation. Debian, for example, also holds to this interpretation and will
reject a GPL-incompatible Python package that imports a GPLed Python package as
not legal to distribute.

No court has ever ruled on the issue, and some people, like Larry Rosen, think
it's likely that a judge would not choose the FSF's interpretation. I think
Rosen is probably correct. However, I always assume that the author intends the
FSF's interpretation unless they make an explicit exception, and I respect that
intention.

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

Dec 23 '05 #117
Paul Rubin wrote:
Hmmm. I seem to remember RMS saying that the GPL didn't extend to
Emacs Lisp functions that the user writes, even though those call
various built-in Emacs functions, as long as they use the documented
API. Those certainly run in the same address space as Emacs. This is
the closest thing I can think of to the Karrigell situation.


RMS has said precisely the opposite, in fact.

http://lists.debian.org/debian-legal.../msg00217.html

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

Dec 23 '05 #118
Robert Kern <ro*********@gmail.com> writes:
RMS has said precisely the opposite, in fact.
http://lists.debian.org/debian-legal.../msg00217.html
I guess you mean:
[RMS:]
As for the more general question, we think that a program that uses
Emacs facilities needs to be GPL-covered, but a program that just uses
the Lisp language could have any license--it is not affected by the
license of Emacs.


Hmmm. That seems to say that calling Emacs-specific editing
functions, doing stuff with buffers, etc. implicates the GPL, but
writing a general purpose Lisp program (non-Emacs-specific) and
running it under Emacs does not. That's different from what I'd
thought he'd said about it before, which was that Lisp code that only
used the documented Emacs API didn't implicate the GPL. Thanks for
the link.
Dec 23 '05 #119
Jan Niklas Fingerle <us*********@lithe.de> wrote:
the templating language (Cheetah vs Kid). Those will be points of (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).


If I might add: ElementTree will be part of python 2.5. That's a big
reason to let people import subtrees into the xml template as
ElementTrees. Thus using Kid you can use the standard lib for these
taskts, which would be a big point in favour of Kid.

Anyway, this...
Well, no, make it easy to change templating engines,
whatever you ship as included engine.


.... still holds.

Cheers,
--Jan Niklas
Dec 26 '05 #120
On December 15, 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...
Alex


Hmm, on December 25, I re-did the numbers using google:

rails python django 138,000
rails python subway 66,000
rails python turbogears 46,000

Now, I coudln't resist doing it this way too:

python django 360,000
python subway 690,000
python turbogears 127,000

Unfortunately, no compelling trend emerges. This is the problem, I
think, no, trend, no clear winner (other than Rails;-)))

Python web frameworks, for the love of God, UNITE!!!!

Ron Stephens

Dec 26 '05 #121
One last comment:

This will work, I think, if and only if the "Consolidating" framework,
the one to be used to absorb the other(s) best aspects, makes immediate
and up-front, highly visible concession(s) so as to clearly
communicate a win-win scenario.

Dec 26 '05 #122
Yes, there is a clear winner : "python zope" = 3.950.000

Pierre

Dec 27 '05 #123

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

23 posts views Thread by flab ba | last post: by
reply views Thread by Alessandro Bottoni | last post: by
3 posts views Thread by anakreon | last post: by
2 posts views Thread by chardish | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.