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 else. -- http://mail.python.org/mailman/listinfo/python-list