Which Python web framework is most like Ruby on Rails?

[Mike Meyer]

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

[Robert Kern]

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

[unknown]

However the work I do is commercial and proprietary and I doubt
I could get approval to release it under GPL.

I see the GPL is a problem in this environment, and you are clearly
aware of the issues it raises. Do be aware, though, that not all GPL
authors are rabid communists, and some will consider licensing to you
under other licenses if you ask them. It's always worth asking, as
some authors have chosen GPL in a somewhat uninformed way rather than
as a political statement (you'll notice I too am trying to avoid the
flame wars).

I'm trying to avoid flame wars too, but my take on this is that Kent's
reading is a little too restrictive and the GPL isn't really a problem
in this situation unless he's actually modifying Karrigell itself,
rather than writing applications that run under it. I'm not trying to
advocate Karrigell (I browsed the docs for a minute and it looks nice
but I have no experience with it) but I don't see the GPL as an
obstacle to that type of usage. All kinds of proprietary applications
are written and distributed all the time to run under the GPL'd Linux
kernel and Karrigell apps don't seem too terribly different from that.

[Pierre Quentel]

Hello all,

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 ?

Regards,
Pierre

[Scott David Daniels]

You will hear valid arguments for GPL, LGPL, BSD and other licenses (though
the Python license is unsuitable for anything other than Python - see
http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq)
A good solution would be multiple-licensing. You state that the code is
(for example) triple-licensed under the GPL, LGPL and BSD licenses.

One lawyer I talked to (who could not understand why I wanted to
open-source any code), claimed that the MIT license is better
written (legally) to protect the author from acquiring legal
liability.

--Scott David Daniels
scott.daniels at acm.org

[Fredrik Lundh]

Post by Pierre Quentel
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/PythonSoftwareFoundationLicenseFaq

</F>

[unknown]

Unfortunately, that doesn't really satisfy the GPL's concerns. The work
arguably "contains or is derived from" Karrigell,

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
Linux kernel is GPL but that doesn't mean every Linux app that calls
through the kernel through its documented API is affected. The Linux
kernel GPL only comes into play if you start modifying the kernel, not
writing programs that use it.

which is explicitly covered in section 2b of the GPL. If you start
excluding key clauses from the GPL, then there's little point using it.

There should be no exclusion.

To cut a long story short, and to avoid quibbling over the details of
how a license designed with the low-level mechanics of C-style programs
and libraries in mind actually applies to a language like Python with
very loose coupling, I'll just say that this sort of situation is
exactly what the LGPL exists for.

The LGPL has fallen into some disfavor at the FSF, and I don't see
Karrigell as a library. The application is not an integrated blob
combining Karrigell and user code, from what I can tell. Rather, the
user code is run under Karrigell's control, like Karrigell itself
is run under the Python interpreter.

I would suggest the author adopts the LGPL as a good compromise
between the community benefits of GPL and the user benefits of, say,
BSD or zlib licenses.

But that doesn't gain the community benefits of the GPL since it
foregoes the possibility of users improving Karrigell by incorporating
other GPL'd code into it and distributing the improved version.

[unknown]

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.

[Ben Sizer]

Post by unknown

Unfortunately, that doesn't really satisfy the GPL's concerns. The work
arguably "contains or is derived from" Karrigell,

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.

Post by unknown
The LGPL has fallen into some disfavor at the FSF, and I don't see
Karrigell as a library.

The LGPL ultimate subverts the intent of the GPL in that it lets people
use open source code without having to give much back. Still, it is
'better' in that regard than BSD or zlib. The only practical difference
in this case would be that the LGPL makes it clear that there's a
separation between your code and Karrigell code.

Post by unknown
The application is not an integrated blob
combining Karrigell and user code, from what I can tell. Rather, the
user code is run under Karrigell's control, like Karrigell itself
is run under the Python interpreter.

I see your point, but I think 95% of Karrigell apps will end up making
calls back into the framework. The intent of the GPL is arguably that
if you rely directly upon some GPL code for your application, your app
falls under the license.

From: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation :

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

By contrast, pipes, sockets and command-line arguments are
communication mechanisms normally used between two separate programs.
So when they are used for communication, the modules normally are
separate programs. But if the semantics of the communication are
intimate enough, exchanging complex internal data structures, that too
could be a basis to consider the two parts as combined into a larger
program. "

This is largely academic since the author seems willing to reconsider
the license; but it's an interesting point for applications like this
generally, especially in Python where 'linking' is a little less
stringently defined than in C/C++.

[unknown]

(Responding to several posts)

Post by Ben Sizer

Post by unknown
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]

Post by Ben Sizer
That's silly, you might as well just use BSD instead of triple
licensing like that.
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.

[unknown]

RMS has said precisely the opposite, in fact.
http://lists.debian.org/debian-legal/2002/11/msg00217.html
[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.

[Richie Hindle]

[Paul]

Post by unknown
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

[Kent Johnson]

Post by unknown
[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

[Robert Kern]

Post by unknown
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/2002/11/msg00217.html

[Pierre Quentel]

In Karrigell the scripts are executed in a namespace prepared by the
framework, with HTTP environment, form data, the functions and
exceptions for authentication, session management, redirection etc.
I suppose that this falls into the first category above, "modules
(that) are designed to run linked together in a shared address space" ;
the link between the framework and the scripts is certainly much
tighter than between a web server and a CGI script

Pierre

[Raffaele Salmaso]

Post by Pierre Quentel
Hello all,
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 ?

I think you should use the BSD or the Python License.
I've choose the BSD for my works, with these clauses (my intentions are
clearly stated, so no misinterpretation should be done):

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. If the binary program depends on a modified version of this package,
you are encouraged to publicly release the modified version of this
package.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

And it is almost the same of CherryPy, which you use.

[Martin Christensen]

Ben> Unfortunately, that doesn't really satisfy the GPL's concerns.
Ben> The work arguably "contains or is derived from" Karrigell, which
Ben> is explicitly covered in section 2b of the GPL. If you start
Ben> excluding key clauses from the GPL, then there's little point
Ben> using it.

You will also notice that section 2b of the GPL only applies to works
that are published or distributed, and if a company bases its web site
on Karrigell or any other GPL'ed web framework but does not share the
code with anyone, it cannot be considered to be published nor
distributed. Hence the GPL is a perfectly fine license for this kind
of use.

Martin

[Ben Sizer]

Post by Martin Christensen
Ben> Unfortunately, that doesn't really satisfy the GPL's concerns.
Ben> The work arguably "contains or is derived from" Karrigell, which
Ben> is explicitly covered in section 2b of the GPL. If you start
Ben> excluding key clauses from the GPL, then there's little point
Ben> using it.
You will also notice that section 2b of the GPL only applies to works
that are published or distributed, and if a company bases its web site
on Karrigell or any other GPL'ed web framework but does not share the
code with anyone, it cannot be considered to be published nor
distributed. Hence the GPL is a perfectly fine license for this kind
of use.

You're right, but, Kent said earlier in the thread that "Most of my
projects at least have the potential of being distributed to customers
and GPL is not an option." I was addressing this concern specifically.

[Alex Martelli]

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

But the Python license allows for this too, and Python hasn't
suffered for it.

That Python hasn't suffered for it is a questionable assertion.

Feel free to question it, then -- but "the burden of proof is on the
positive", by normal rules of debate. Where are the versions of Python
made proprietary by exploiting its unGPLness? OTOH, I don't consider it
a "suffering to Python" that it gets embedded for scripting tasks in
such closed-source apps as Poser or Civilization IV: I believe (and you
can check with the respective companies) that since those companies had
chosen closed-source as their main business strategy, if embedding
Python had forced them to opensource their "engines" they'd simply have
chosen another language for their scripting part (indeed, too many
proprietary apps already use proprietary scripting languages for the
silliest reasons -- giving them another reason would be a disaster).
At the same time Python also thrives in open-source apps such as OO.o,
just about all Linux distros, and so on, and so forth.


Alex

[unknown]

Post by Pierre Quentel
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 ?

My own hope (not shared by everyone obviously) is that you will stay
with the GPL, but make clear that applications that simply run under
Karrigell but don't modify the Karrigell code aren't subjected to the
GPL. That should satisfy Kent's concerns.

See http://www.gnu.org/philosophy/pragmatic.html for some reasons to
use the GPL.

French version: http://www.gnu.org/philosophy/pragmatic.fr.html

[Ben Sizer]

Post by unknown

Post by Pierre Quentel
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 ?

My own hope (not shared by everyone obviously) is that you will stay
with the GPL, but make clear that applications that simply run under
Karrigell but don't modify the Karrigell code aren't subjected to the
GPL. That should satisfy Kent's concerns.

Unfortunately, that doesn't really satisfy the GPL's concerns. The work
arguably "contains or is derived from" Karrigell, which is explicitly
covered in section 2b of the GPL. If you start excluding key clauses
from the GPL, then there's little point using it.

To cut a long story short, and to avoid quibbling over the details of
how a license designed with the low-level mechanics of C-style programs
and libraries in mind actually applies to a language like Python with
very loose coupling, I'll just say that this sort of situation is
exactly what the LGPL exists for. I would suggest the author adopts the
LGPL as a good compromise between the community benefits of GPL and the
user benefits of, say, BSD or zlib licenses.

[Richie Hindle]

[Pierre]

Post by Pierre Quentel
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 ?

Well done on being open-minded!

You will hear valid arguments for GPL, LGPL, BSD and other licenses (though
the Python license is unsuitable for anything other than Python - see
http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq)

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

The only downside of allowing people to choose the BSD license rather than
the GPL is that potentially someone can choose the BSD license, improve
Karrigell, ship their product based on the improved code, and not give those
improvements back to the community. But the Python license allows for this
too, and Python hasn't suffered for it. IMO choosing a BSD license will get
you more users than GPL, and the benefits of that will outweigh the
potential downside.

[Pierre Quentel]

I definitely don't want to invent another licence, there are enough of
them already !
Pierre

[Fuzzyman]

BSD license is good. It requires that your copyright notice be included
with any derivative works - but otherwise lets users create and
distribute derivatives how they see fit. The version I use is at
http://www.voidspace.org.uk/python/license.shtml (which links to the
version at the OSI).

The MIT license is even *less* restrictive. I would use one or other of
these two.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

[Kent Johnson]

Post by unknown
I'm trying to avoid flame wars too, but my take on this is that Kent's
reading is a little too restrictive and the GPL isn't really a problem
in this situation unless he's actually modifying Karrigell itself,
rather than writing applications that run under it. I'm not trying to
advocate Karrigell (I browsed the docs for a minute and it looks nice
but I have no experience with it) but I don't see the GPL as an
obstacle to that type of usage. All kinds of proprietary applications
are written and distributed all the time to run under the GPL'd Linux
kernel and Karrigell apps don't seem too terribly different from that.

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?

Indeed. But most software authors aren't lawyers and aren't likely to
trust their own judgment about these matters unless the situation is
pretty unambiguous.

That really is the issue as much as anything. Paul has raised some good questions for
which I don't have good answers. Maybe using Karrigell is analogous to writing an app to
run on Linux. OTOH maybe it is more like linking to a library. I could ask the author for
clarification - which I would then have to document in a form acceptable to my own
company's lawyers. Or I could choose to use a product that doesn't leave any doubt that I
can distribute it as I like in a proprietary product.

I suspect this may be evidence that Microsoft's
"viral" propaganda has had some effect.

Not in my case, at least. I have been avoiding GPL products at work for many years, much
longer than Microsoft has been telling me to do so.

In this case I agree there's likely to be a clear separation between
server and content that will allow Kent to distribute an unmodified
Karrigell and a separate proprietary content bundle without
interference, but it's too late (at least for that project) now.

Maybe next time...

Kent

[unknown]

Indeed. But most software authors aren't lawyers and aren't likely to
trust their own judgment about these matters unless the situation is
pretty unambiguous. I suspect this may be evidence that Microsoft's
"viral" propaganda has had some effect.

Hmm, good point.

In this case I agree there's likely to be a clear separation between
server and content that will allow Kent to distribute an unmodified
Karrigell and a separate proprietary content bundle without
interference, but it's too late (at least for that project) now.

Oh well.

[gene tani]

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

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

Post by 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 ?

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

<mike

[Ben Sizer]

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.

[unknown]

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

[Dave Benjamin]

Post by unknown

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

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

[Mike Meyer]

Post by Ben Sizer
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.

Post by Ben Sizer
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.

Post by Ben Sizer
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

[Russell E. Owen]

In article <86lkykuao4.fsf at bhuda.mired.org>, Mike Meyer <mwm at mired.org>

Post by Mike Meyer

Post by Ben Sizer
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

[Russell E. Owen]

In article <mailman.2324.1135035015.18701.python-list at python.org>,

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.

I just wanted to point out that I was responding to somebody who
complained that the database interface situation on python was somewhat
fragmented.

Also, when I was looking at web frameworks, I was doing so *precisely*
to serve one or more databases of information (read only to the users,
but occasionally loaded with more info as it became available). So it
happened to be the first question I asked (at the same time as "and how
do I talk to it?").

Anyway, you did warn that your message was possibly off-topic, so I
guess I'm agreeing with you and perhaps being overly defensive. It was
an interesting message.

-- Russell

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

[Robert Kern]

...

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.

[A.M. Kuchling]

On Thu, 15 Dec 2005 20:15:17 -0800,

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

[Alex Martelli]

gene tani <gene.tani at 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

[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

[Gregory Petrosyan]

+1 for Kid -- it's more pythonic IMHO.

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

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

Post by chuck

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

Post by chuck

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

[Alex Martelli]

Robert Kern <robert.kern at 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

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

[Mike Meyer]

Post by chuck
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.

Post by chuck
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]

...

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

[unknown]

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]

Post by unknown

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

[Russell E. Owen]

In article <7xbqzhr7qj.fsf at ruckus.brouhaha.com>,

Post by unknown

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

[Ed Singleton]

On Thu, 22 Dec 2005 14:05:08 +0000,

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"

[Kent Johnson]

On 20 Dec 2005 15:05:15 -0800,

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

[A.M. Kuchling]

On 20 Dec 2005 15:05:15 -0800,

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

[A.M. Kuchling]

On Thu, 22 Dec 2005 14:05:08 +0000,

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

[Ed Singleton]

On 20 Dec 2005 15:05:15 -0800,

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

[Michael Tobis]

Clearly the Ruby/Rails folks are making an effort to place themselves
as an easy-to-learn first language for people who might otherwise drift
into the rather awkward template-first way of thinking that is PHP.

I note that the Rails people are closely affiliated with the 37signals
people who in turn are closely linked with some advertising
professionals.

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
that this makes for amazing brilliance that is more or less invisible
to most of the world.

This leaves me believing that the commercial future is probably
brighter for Ruby vs Python. This won't affect the fact that Python is
probably still going to prevail in the scientific community, since
scientists aren't all that susceptible to promotion. That being the
case I don't think I myself will jump ship.

Since I am casting my lot with Python rather than Ruby, I think we
should take the friendly rivalry seriously rather than just shrugging
it off. Python MUST attract some of the most promising novice
programmers, and I believe that was part of its original design.

As a consequence Python MUST settle on a strong web framework that
includes the best of the existing frameworks, and polish it for maximum
accessibility as well as power.

Just on the basis of momentum rather than any strong technical argument
(which I am not well-qualified to make) I suggest we consider settling
on Django and doing what we can to improve it and its documentation.

mt

[gene tani]

Post by Robert Kern
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.

[DH]

Post by Alex Martelli
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.

[Mike Meyer]

[Not sure if this attribution is correct.]

And it was apparently wrong. Apologies to both DH and AM.

Post by DH
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

[gene tani]

Post by DH
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"?!

[Ben Sizer]

[Not sure if this attribution is correct.]

Post by DH
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.

[Mike Meyer]

[Not sure if this attribution is correct.]

Post by DH
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

[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

[Mike Meyer]

Post by Alia Khouri
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

[gene tani]

Post by Alia Khouri
"Conquest is a method of union.

...

Post by Alia Khouri
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

[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

[gene tani]

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.

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

[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

[unknown]

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

[Robert Kern]

Post by unknown

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.

[Pierre Quentel]

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

[Mike Meyer]

IANAL but that is not my understanding of the GPL. GPL version 2
section 2.b) reads, "You must cause any work that you distribute or
publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License." My server would
certainly be a work that in part contains Karrigell.

Your web app and html files would IMO be considered a separate work,
like C programs that you compile with GCC. If they don't contain actual
Karrigell code and they're not derived from Karrigell code, then I'd
think 2.b) doesn't apply. The test I'd use is, imagine you don't have
the Karrigell distro and you only have a printout of the documentation.
Can you write your app from just the docs? IANAL, etc., and to be
safe, you could simply ask the Karrigell author.

That's one test. Another one is whether you can distribute your app as
one piece and let them get Karrigell from somewhere else to put things
together. If they can set up your app without copying parts of
Karrigel into it (and you didn't do that for them), then you're
ok. You can even bundle Karrigel into the distribution for them.

While them having to modify Karrigel extensively to work with your app
- for instance, if you distributed patch files - is within the letter
of the license, the FSF considers such a violation. IIRC, they gave
NeXT shit for doing this.

<mike

[Jeff Rush]

Post by Luis M. Gonzalez
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

[unknown]

I did make some changes to CherryPy. I wouldn't mind sharing those
changes back with the CherryPy community. But the product was the
server itself, not the web site. As I understand the GPL the server
software would be a "work based on the [GPL-licensed] Program" and
thus subject to the GPL itself.

Yes, correct.

I'm not sure what you mean by "simply developing content". I was
developing a web application, not a web site serving static HTML.

Yes, that is content.

The bulk of the development work was writing Python code that worked
with CherryPy.

And also with the Python interpreter. If the Python interpreter were
GPL'd, would that have been an issue?

Remember that the GPL only applies to the code of Karrigell
itself, not to stuff that you write using it.

IANAL but that is not my understanding of the GPL. GPL version 2
section 2.b) reads, "You must cause any work that you distribute or
publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License." My server would
certainly be a work that in part contains Karrigell.

Your web app and html files would IMO be considered a separate work,
like C programs that you compile with GCC. If they don't contain actual
Karrigell code and they're not derived from Karrigell code, then I'd
think 2.b) doesn't apply. The test I'd use is, imagine you don't have
the Karrigell distro and you only have a printout of the documentation.
Can you write your app from just the docs? IANAL, etc., and to be
safe, you could simply ask the Karrigell author.

[Kent Johnson]

Remember that the GPL only applies to the code of Karrigell
itself, not to stuff that you write using it.

IANAL but that is not my understanding of the GPL. GPL version 2
section 2.b) reads, "You must cause any work that you distribute or
publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License." My server would
certainly be a work that in part contains Karrigell.

Your web app and html files would IMO be considered a separate work,
like C programs that you compile with GCC. If they don't contain actual
Karrigell code and they're not derived from Karrigell code, then I'd
think 2.b) doesn't apply. The test I'd use is, imagine you don't have
the Karrigell distro and you only have a printout of the documentation.
Can you write your app from just the docs? IANAL, etc., and to be
safe, you could simply ask the Karrigell author.

You've lost me here. The server certainly would contain Karrigell code, it wouldn't
function without it. I don't understand the analogy to GCC, the web site is not something
that is compiled with Karrigell. Karrigell is a library or framework that is an essential
part of the server. I don't know how I would write the app without Karrigell.

A FAQ entry attempts to shed light on the question but just confuses me more. "If the two
programs remain well separated ... then you can treat them as two separate programs--but
you have to do it properly. The issue is simply one of form." WTF?
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

I confess, one reason I stay away from the GPL and even LGPL is because no matter how many
times I read them I'm not sure what they really say. FAQs like the above certainly don't
help much. In contrast the (BSD-style) CherryPy license is crystal clear.

Kent

[unknown]

Post by Kent Johnson
You've lost me here. The server certainly would contain Karrigell
code, it wouldn't function without it. I don't understand the analogy
to GCC, the web site is not something that is compiled with
Karrigell. Karrigell is a library or framework that is an essential
part of the server. I don't know how I would write the app without Karrigell.

Let me ask it this way: suppose you used ASP instead. As I understand
ASP, it's like PHP except it's proprietary. Would ASP's license be a
problem?

Maybe you're using "the server" to encompass too much. If I have an
Apache-based web site, then the web server is Apache. If I have a
Python CGI script that the Apache server runs, the CGI script is not
"the server"--it's an application running under the server. It would
not be affected by the GPL if Apache used the GPL. Karrigell scripts
seem to me to work out about the same way.

[Kent Johnson]

Post by unknown

Post by Kent Johnson
You've lost me here. The server certainly would contain Karrigell
code, it wouldn't function without it. I don't understand the analogy
to GCC, the web site is not something that is compiled with
Karrigell. Karrigell is a library or framework that is an essential
part of the server. I don't know how I would write the app without Karrigell.

Let me ask it this way: suppose you used ASP instead. As I understand
ASP, it's like PHP except it's proprietary. Would ASP's license be a
problem?
Maybe you're using "the server" to encompass too much. If I have an
Apache-based web site, then the web server is Apache. If I have a
Python CGI script that the Apache server runs, the CGI script is not
"the server"--it's an application running under the server. It would
not be affected by the GPL if Apache used the GPL. Karrigell scripts
seem to me to work out about the same way.

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.

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?

Kent

[unknown]

I chose CherryPy in part because its license allows this. I
would have considered Karrigell if it had a different license.

Have you had to modify CherryPy in some substantive way that you
needed to keep proprietary, as opposed to simply developing content
that CherryPy serves but is completely independent of CherryPy's
license?

I notice that a heck of a lot of commercial users are using completely
proprietary packages like ASP, whose licenses are far more restrictive
than the GPL. They don't seem to think it's a problem. So for most
such users, Karrigell shouldn't be a problem either. Remember that
the GPL only applies to the code of Karrigell itself, not to stuff
that you write using it.

[Luis M. Gonzalez]

I don't think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

[Arthur Clune]

OK I'll try. First let me say I have no interest in a licensing flame war, there are valid
reasons why an author might prefer one license over another and certainly there are good
reasons to choose GPL. However the work I do is commercial and proprietary and I doubt I
could get approval to release it under GPL. So I am restricted to projects with more
liberal licenses such as MIT, BSD and Apache licenses. These allow closed-source
distribution of products based on them.

As long as the author holds copyright on all the code, he can release it to you under
any license he wants, as well as via GPL to the world (this is how MySQL and SleepyCat
opterate).

So you could, for example, offer him X pounds/dollars/euros for a BSD version + support
etc.

Arthur

[Kent Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kent> [Karrigell is GPL'ed] Unfortunately this makes it impossible for
Kent> me to consider using Karrigell in my work. I recently needed a
Kent> stand-alone web server for a small in-house project that might
Kent> possibly be distributed to business partners or become a product
Kent> some day. I chose CherryPy in part because its license allows
Kent> this. I would have considered Karrigell if it had a different
Kent> license.
None of this really matters, you know. The GPL only requires that you
share your source code if you _distribute_ your modifications. Since
you make your modifications exclusively for your own (your company's)
use, you are not required to share anything. Thus the whole debate is
pretty much moot if I am not much mistaken.

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

Kent

[Steve Holden]

Post by Luis M. Gonzalez
I don't think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

OK I'll try. First let me say I have no interest in a licensing flame war, there are valid
reasons why an author might prefer one license over another and certainly there are good
reasons to choose GPL. However the work I do is commercial and proprietary and I doubt I
could get approval to release it under GPL. So I am restricted to projects with more
liberal licenses such as MIT, BSD and Apache licenses. These allow closed-source
distribution of products based on them.

I see the GPL is a problem in this environment, and you are clearly
aware of the issues it raises. Do be aware, though, that not all GPL
authors are rabid communists, and some will consider licensing to you
under other licenses if you ask them. It's always worth asking, as some
authors have chosen GPL in a somewhat uninformed way rather than as a
political statement (you'll notice I too am trying to avoid the flame wars).

Certainly it is within an author's rights to prohibit use of his code in closed source
products, as the author of Karrigell has done by choosing GPL and I respect this decision.
Unfortunately this makes it impossible for me to consider using Karrigell in my work. I
recently needed a stand-alone web server for a small in-house project that might possibly
be distributed to business partners or become a product some day. I chose CherryPy in part
because its license allows this. I would have considered Karrigell if it had a different
license.

As we say in Yorkshire, "You get nowt if you don't ask".

regards
Steve

[Kent Johnson]

Post by Luis M. Gonzalez
I don't think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

OK I'll try. First let me say I have no interest in a licensing flame war, there are valid
reasons why an author might prefer one license over another and certainly there are good
reasons to choose GPL. However the work I do is commercial and proprietary and I doubt I
could get approval to release it under GPL. So I am restricted to projects with more
liberal licenses such as MIT, BSD and Apache licenses. These allow closed-source
distribution of products based on them.

Certainly it is within an author's rights to prohibit use of his code in closed source
products, as the author of Karrigell has done by choosing GPL and I respect this decision.
Unfortunately this makes it impossible for me to consider using Karrigell in my work. I
recently needed a stand-alone web server for a small in-house project that might possibly
be distributed to business partners or become a product some day. I chose CherryPy in part
because its license allows this. I would have considered Karrigell if it had a different
license.

Kent

[unknown]

Post by Luis M. Gonzalez
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

See:
http://www.gnu.org/philosophy/pragmatic.html

[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

[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

[Scott David Daniels]

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.

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
scott.daniels at acm.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.

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

[unknown]

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.

[Jorge Godoy]

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

[unknown]

Post by Mike Meyer
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.

Post by Mike Meyer
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.

Post by Mike Meyer
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 Boddie]

Post by unknown
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

[Steve Holden]

Post by Paul Boddie

Post by unknown
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.

And with the proper technology, you can get the best of both
worlds. You build the site as dynamically genrated, then "compile" it
to get the static pages you actually serve. That way you get all the
benefits you listed of serving static pages, plus the ability to use a
database and all it's associated tools for maintaining your data (if
you consider that an advantage, anyway).

That's an approach I'm currently experimenting with - the content of
www.holdenweb.org is mostly static but generated from a database, and
the current tasks include completing a wxPython database maintenance
GUI, incorporating various ways to generate scripted content that
matches the look and feel of the rest of the site and adding more and
more ways to generate the interior content.

It's obvious by comparison with www.holdenweb.com that there's a good
deal of design commonality.

I'll be looking for beta testers eventually ...

regards
Steve

[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

[UrsusMaximus]

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.

[Dody Suria Wijaya]

Django is the closest one.

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

[Pierre Quentel]

Yes, there is a clear winner : "python zope" = 3.950.000

Pierre