Yes, there is a clear winner : python zope = 3.950.000
Pierre
--
http://mail.python.org/mailman/listinfo/python-list
On December 15, Alex Martelli wrote:
Alternatively, counting Google hits:
rails python django 112,000
rails python subway 81,600
rails python turbogears 32,000
This isn't exactly buzz, of course, but it's SOME measure of critical
mass -- and with django about equal to
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.
--
Robert Kern [EMAIL PROTECTED] writes:
RMS has said precisely the opposite, in fact.
http://lists.debian.org/debian-legal/2002/11/msg00217.html
I guess you mean:
[RMS:]
As for the more general question, we think that a program that uses
Emacs facilities needs to be GPL-covered, but a program
[Paul]
The web app gets run by Karrigell like a CGI script
is run by Apache, like a Linux app is run by the Linux kernel.
Paul, you keep making comparisons between Python web frameworks and the
Linux kernel. Are you aware that there is a special note attached to the
Linux GPL[1] explaining
Richie Hindle [EMAIL PROTECTED] writes:
Paul, you keep making comparisons between Python web frameworks and the
Linux kernel. Are you aware that there is a special note attached to the
Linux GPL[1] explaining that user-space code is not considered a derived
work of the Linux kernel? Without
On 20 Dec 2005 15:05:15 -0800,
Michael Tobis [EMAIL PROTECTED] wrote:
Python people don't really think that way. As a community we really
seem to inherit the open source dysfunction of trying harder to impress
each other than to reach out to the rest of the world. The problem is
Yes;
On 22/12/05, A.M. Kuchling [EMAIL PROTECTED] wrote:
On 20 Dec 2005 15:05:15 -0800,
Michael Tobis [EMAIL PROTECTED] wrote:
Python people don't really think that way. As a community we really
seem to inherit the open source dysfunction of trying harder to impress
each other than to
On Thu, 22 Dec 2005 14:05:08 +,
Ed Singleton [EMAIL PROTECTED] wrote:
Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.
A good start would be for there to be a way for newbies
On 22/12/05, A.M. Kuchling [EMAIL PROTECTED] wrote:
On Thu, 22 Dec 2005 14:05:08 +,
Ed Singleton [EMAIL PROTECTED] wrote:
Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.
A.M. Kuchling wrote:
On 20 Dec 2005 15:05:15 -0800,
Michael Tobis [EMAIL PROTECTED] wrote:
Python people don't really think that way. As a community we really
seem to inherit the open source dysfunction of trying harder to impress
each other than to reach out to the rest of the world.
On 21 Dec 2005 13:53:55 -0800, Pierre Quentel [EMAIL PROTECTED] wrote:
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 : ? +
Kent Johnson wrote:
Luis M. Gonzalez wrote:
The only problem with KARRIGELL, I guess, is that its creator is very
humble and doesn't like to advertise his creature. He is not very fond
of marketing ...
From my point of view the biggest problem with Karrigell is that it is
released
Jeff Rush [EMAIL PROTECTED] writes:
Your only solution would be a proprietary license that states you
purchased this program and don't have the right to pass it on to
others, similar to ActiveState or somesuch.
It sounds like that's what Kent wants to do with the apps that he's
building.
Paul Rubin wrote:
Jeff Rush [EMAIL PROTECTED] writes:
Your only solution would be a proprietary license that states you
purchased this program and don't have the right to pass it on to
others, similar to ActiveState or somesuch.
It sounds like that's what Kent wants to do with the apps that
Paul Rubin wrote:
Hmmm. I seem to remember RMS saying that the GPL didn't extend to
Emacs Lisp functions that the user writes, even though those call
various built-in Emacs functions, as long as they use the documented
API. Those certainly run in the same address space as Emacs. This is
Kent Johnson wrote:
Luis M. Gonzalez wrote:
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
Steve Holden [EMAIL PROTECTED] writes:
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
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 ?
Pierre Quentel [EMAIL PROTECTED] writes:
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
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
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
Steve Holden [EMAIL PROTECTED] writes:
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,
I definitely don't want to invent another licence, there are enough of
them already !
Pierre
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
Pierre Quentel [EMAIL PROTECTED] writes:
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
Ben Sizer [EMAIL PROTECTED] writes:
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
[Pierre]
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 ?
Richie Hindle [EMAIL PROTECTED] writes:
A good solution would be multiple-licensing. You state that the
code is (for example) triple-licensed under the GPL, LGPL and BSD
licenses. The user of your code decides which license to obey.
It's no more work for you, and you can please almost
Steve Holden wrote:
Paul Rubin wrote:
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
Pierre Quentel ha scritto:
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
Kent Johnson wrote:
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
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
Paul Rubin wrote:
Kent Johnson [EMAIL PROTECTED] writes:
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
Paul Rubin wrote:
Ben Sizer [EMAIL PROTECTED] writes:
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
Richie Hindle wrote:
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kent == Kent Johnson [EMAIL PROTECTED] writes:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben == Ben Sizer [EMAIL PROTECTED] writes:
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
Martin Christensen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kent == Kent Johnson [EMAIL PROTECTED] writes:
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
Martin Christensen wrote:
Kent == Kent Johnson [EMAIL PROTECTED] writes:
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
Paul Rubin http://[EMAIL PROTECTED] wrote:
Richie Hindle [EMAIL PROTECTED] writes:
A good solution would be multiple-licensing. You state that the
code is (for example) triple-licensed under the GPL, LGPL and BSD
licenses. The user of your code decides which license to obey.
It's no
Martin Christensen wrote:
Ben == Ben Sizer [EMAIL PROTECTED] writes:
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
Pierre Quentel wrote:
I am Karrigell's author. I have chosen the GPL licence almost at random
(I saw that the Python licence was GPL-compatible), so I don't mind
switching to another Open Source licence if the GPL is liable to cause
problems. Which one would you advice : BSD ? Python licence
Alex Martelli wrote:
Paul Rubin http://[EMAIL PROTECTED] wrote:
Richie Hindle [EMAIL PROTECTED] writes:
A good solution would be multiple-licensing. You state that the
code is (for example) triple-licensed under the GPL, LGPL and BSD
licenses. The user of your code decides which license to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kent == Kent Johnson [EMAIL PROTECTED] writes:
Kent In the text you quoted I said, a small in-house project that
Kent might possibly be distributed to business partners or become a
Kent product some day. Sounds like distribution to me.
My bad. I
(Responding to several posts)
Ben Sizer [EMAIL PROTECTED] writes:
I don't see that. The web app gets run by Karrigell like a CGI script
is run by Apache, like a Linux app is run by the Linux kernel.
The web app uses parts of Karrigell though - things like the QUERY
variable or or Session
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
Paul Rubin wrote:
[Kent Johnson]
Where would you draw the line? Suppose I want to use a GPLed library
in my Python code, does that mean I have to distribute my code under
the GPL if I distribute them together?
Yes, that's the point of using the GPL on a library instead of
Paul Rubin wrote:
Russell E. Owen [EMAIL PROTECTED] writes:
I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python. Also, typically either:
- One stands out (because others have been abandoned or
Paul Rubin wrote:
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
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
Oops! Second line on the home page:
snipWith 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
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
Paul Boddie [EMAIL PROTECTED] writes:
Paul Rubin wrote:
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.
Mike Meyer wrote:
Paul Boddie [EMAIL PROTECTED] writes:
Paul Rubin wrote:
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
Luis M. Gonzalez wrote:
The only problem with KARRIGELL, I guess, is that its creator is very
humble and doesn't like to advertise his creature. He is not very fond
of marketing ...
From my point of view the biggest problem with Karrigell is that it is
released under the
GPL. Most of my
In article [EMAIL PROTECTED],
Benji York [EMAIL PROTECTED] wrote:
Russell E. Owen wrote:
I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python.
Perhaps it's off-topic for this thread, but I think
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...
--
http://mail.python.org/mailman/listinfo/python-list
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 think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Luis M. Gonzalez [EMAIL PROTECTED] writes:
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
--
http://mail.python.org/mailman/listinfo/python-list
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
Luis M. Gonzalez wrote:
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
Kent Johnson [EMAIL PROTECTED] writes:
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
Paul Rubin wrote:
Kent Johnson [EMAIL PROTECTED] writes:
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,
I did make
Kent Johnson [EMAIL PROTECTED] writes:
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]
Paul Rubin http://[EMAIL PROTECTED] writes:
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
Paul Rubin wrote:
Kent Johnson [EMAIL PROTECTED] writes:
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
Kent Johnson [EMAIL PROTECTED] writes:
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
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/
--
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Alex Martelli) writes:
To put it another way: one reason I love Python is that I strongly
subscribe to the idea that there should preferably be only one obvious
way to do something. Unfortunately,
In article [EMAIL PROTECTED], Mike Meyer [EMAIL PROTECTED]
wrote:
Ben Sizer [EMAIL PROTECTED] writes:
I see what you mean, but unfortunately I think there is a lot more
fuzziness than that. If the separate parts were clearly delineated
things would be a lot better. I look to the Database API
Russell E. Owen [EMAIL PROTECTED] writes:
I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python. Also, typically either:
- One stands out (because others have been abandoned or whatever), so
there's
Russell E. Owen wrote:
I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python.
Perhaps it's off-topic for this thread, but I think picking a database
is the first mistake most people make. It's a form
Benji York [EMAIL PROTECTED] writes:
Russell E. Owen wrote:
I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python.
Perhaps it's off-topic for this thread, but I think picking a
database is the first
Mike Meyer [EMAIL PROTECTED] writes:
What makes me think I need a database is a requirement that says
multiple simultaneous writers.
I'd go a little further and say multiple simultaneous writers doing
multi-step transactions with steps that can have high latency,
e.g. transactions that have to
Paul Rubin http://[EMAIL PROTECTED] writes:
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,
On Mon, 19 Dec 2005, Paul Rubin wrote:
Russell E. Owen [EMAIL PROTECTED] writes:
I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python. Also, typically either:
- One stands out (because others have been
Scott David Daniels [EMAIL PROTECTED] wrote:
Mike Meyer wrote:
Benji York [EMAIL PROTECTED] writes:
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
Alex Martelli wrote:
Scott David Daniels [EMAIL PROTECTED] wrote:
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
[EMAIL PROTECTED] writes:
Mike Meyer wrote:
It's conceivable that a change might make Python more popular and also
detract from the language in some way. For a ridiculous example,
making Python interpret Perl 6 would certainly make it more popular,
but I would argue that would seiously
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
--
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
On Thu, 15 Dec 2005 20:15:17 -0800,
Alex Martelli [EMAIL PROTECTED] wrote:
If you claim there's a web project that's unfeasible to do in Ruby,
you'd better come up with a strong example. If you're making no such
claim, which would be counter to the claims of the Ruby community, then
Mike Meyer wrote:
Ben Sizer [EMAIL PROTECTED] writes:
Flexibility is good, but personally I think the problem is that instead
of useful variety, we have redundant overlap. How many different
templating systems, sql--object mappings, and URL dispatch schemes do
we need? And what exactly is
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.
Alia Khouri wrote:
In http://subway.python-hosting.com/ticket/216 Peter Mere writes:
Conquest is a method of union.
...
unstoppable juggernaut of
chaos will continue in python web app land,
and ruby will become ascendant. This is more than a critical issue -
don't dismiss it without
chuck [EMAIL PROTECTED] writes:
As I read through this thread I can't say that I disagree that having
more choices is a 'good thing'. However in your example here - I
suspect that you are a bit sharper and have a bit more guts than your
average code slinger since you appear to be an
Ben Sizer [EMAIL PROTECTED] writes:
I see what you mean, but unfortunately I think there is a lot more
fuzziness than that. If the separate parts were clearly delineated
things would be a lot better. I look to the Database API Specification
as a great example of how this could (should?) be
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
Alia Khouri [EMAIL PROTECTED] writes:
If Subway does not unite, chaos will continue in python web app land,
and ruby will become ascendant. This is more than a critical issue -
don't dismiss it without understanding that doing so will have severe
repercussions for subway (and by a process of
chuck [EMAIL PROTECTED] writes:
it would make Python more popular isn't an adequate
justification for a change
I disagree. The world desperately needs programming languages,
frameworks, etc. that allow for the more efficient creation and
maintenance of software application - web or
Mike Meyer wrote:
It's conceivable that a change might make Python more popular and also
detract from the language in some way. For a ridiculous example,
making Python interpret Perl 6 would certainly make it more popular,
but I would argue that would seiously detract from the language.
why
Mike Meyer wrote:
[Not sure if this attribution is correct.]
Alex Martelli wrote:
Because of course if other languages have 1 or two frameworks, python
needs a dozen.
People keep talking about Python's wealth of web frameworks as if it
were a bad thing. I just don't see it. Just like I
Ben Sizer wrote:
Mike Meyer wrote:
[Not sure if this attribution is correct.]
Alex Martelli wrote:
Because of course if other languages have 1 or two frameworks, python
needs a dozen.
woops, that attribution is absolutely *wrong*, DH said that, sorry Alex
--
Ben Sizer wrote:
Mike Meyer wrote:
[Not sure if this attribution is correct.]
Alex Martelli wrote:
Because of course if other languages have 1 or two frameworks, python
needs a dozen.
People keep talking about Python's wealth of web frameworks as if it
were a bad thing. I just
gene tani [EMAIL PROTECTED] wrote:
Ben Sizer wrote:
Mike Meyer wrote:
[Not sure if this attribution is correct.]
Alex Martelli wrote:
Because of course if other languages have 1 or two frameworks, python
needs a dozen.
woops, that attribution is absolutely *wrong*, DH said
Ben Sizer [EMAIL PROTECTED] writes:
Mike Meyer wrote:
[Not sure if this attribution is correct.]
And it was apparently wrong. Apologies to both DH and AM.
Alex Martelli wrote:
Because of course if other languages have 1 or two frameworks, python
needs a dozen.
People keep talking about
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
chuck [EMAIL PROTECTED] wrote:
People keep talking about Python's wealth of web frameworks as if it
were a bad thing.
I disagree somewhat. While variety and choice are nice, sometimes
having too many choices may inhibit people from trying the language
because they don't know where to
Alex Martelli wrote:
I agree with chuck. I've seen excellent programmers explain why for
some urgent problem they chose Ruby on Rails rather than Java or Python:
Ruby has ONE web framework (that matters), so the choice was finished
there; to evaluate properly 50 frameworks for Java or 20 for
Robert Kern [EMAIL PROTECTED] 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
1 - 100 of 118 matches
Mail list logo
