lycka at carmen.se
Fri Jan 20 14:30:21 CET 2006
Fredrik Lundh wrote:
> if you can find one that's relatively stable, simple enough to enable beginners to
> do simple things with just a little python code, can do simple stuff without needing
> a full-blown DB, and can run as an ordinary CGI if necessary, I'm definitely +1.
> (hmm. maybe "web.py" fits the spec? but that's more a library than a frame-
> work, of course...)
For a long time, I used to think that software always belonged
to one of these two groups:
1. Easy to get started with, but doesn't work very well when you
get beyond trivial applications. E.g. MS Access and VB etc.
2. Works well for tough, real world applications, but with a much
higher threshold in the beginning. E.g. Oracle and C++ etc.
(Well, there was obviously completely useless software that was
neither easy nor scalable.)
Then I stumbled over Python, and realized that it doesn't have
to be like that... But that doesn't mean that all software written
in Python has this best-of-both-worlds quality. The plethora of web
kits for Python seems to suggest that noone wrote the "Python" of
Python web kits yet. (On the other hand, if my reasoning here was
sound, I guess everybody would program Python now...)
A type 2 application wouldn't be very helpful in the std lib, and I
think the initial complexity of many of these frameworks or libraries
stem from having grown from something small and simple into something
more featureful, but also relying on third party libraries and external
resources such as databases.
On the other hand, we don't want a type 1 application, or something
that's small and easy to understand simply because it's an immature
product on its way to become a type 2 application.
Maybe the right thing to put into the std lib is the core of one of
the fullblown toll kits. That might require some serious surgery.
Even with web.py, there is some work to get rid of Cheetah
dependencies by writing a replacement. If sqlite would also go
into the stdlib, I guess a std lib web.py should also be adapted
to that, otherwise the db thingies should just be pulled out.
If we look at Zope, It's only now, in Zope 3, after many years and
God knows how many development hours, that we start to see a more
mature, componentized struccture where different parts are usable on
their own and pieces can be unplugged and replaced with something
More information about the Python-list