Pimping the 'cgi' module

[robert]

Christoph Haas wrote:
> On Friday 24 November 2006 13:08, robert wrote:
>> well, note, for that they have named it Ruby-On-Rails, so its still the
>> language - leveraged. While it is Zope/Django/Ego-on-Python ... ?
> 
> If by that you mean that neither Zope nor Django are exactly pythonic I 
> think I concur.

on-python, but not python-on :-) - as we discussed about "framework vs. directness/intuition"
Zope and Django's Ego certainly won't fit into/near the stdlib

>> Unless a Guido'ed version of such thing is not _selected_ into the
>> stdlib or at least promoted single-mindedly and prominently by far
>> before high-tech-but-low-number names like Zope and Django, Python will
>> continue to bleed out heavily on numbers vs. Ruby.
> 
> Guido seems to have been confused about the rank growth of web based 
> frameworks himself. So it's even less likely one of them gets included as 
> part of the standard library in finite time.

Yet so he will decide about the magnitude of order of future Python users. I'm sure the door will open once ..
Py3K will not make as big a change regarding this magnitude. 

>> First need of course: an update of that cgi "module".
> 
> Oh, yeah. I just joined the Web SIG and found out that WSGI seems the way 
> to go. At a first look it seems horrible if you just want to provide a CGI 
> module. But there must be some reason for its existence. :) Looking 
> further through http://wiki.python.org/moin/WebFrameworks my head starts 
> to spin. Somehow I sadly feel I would just add another incomplete 
> framework to that pile.
> 
> I'm especially unsure whether it's good or bad to create another "I'm sick 
> of the standard library"-style module. I've just become a bit less 
> confident to actually contribute something useful there. Overwhelming.

tying selected techniques together on the right level is the task. Its not forbidden to learn a little from Rails and Perl module structure.

>> python-dev is fully occupied with top-notch inner life. Of course that
>> is the basis. But key issues in lib&tools were simply forgotten - left
>> to a random community.
> 
> Which doesn't match the "batteries included" fuss at all. Of course the 
> basis has to be good, too. And there are so many paradigms today that no 
> core-python developer can really be expected to provide good standard 
> modules for everyone.
> 
>> Go for a start. In order to realize that essential batteries in good
>> quality within time - even after 10 years now - it is necessary, to hook
>> python-dev for even requesting it actively. Just adding to
>> http://wiki.python.org/moin/WebProgramming and
>> http://wiki.python.org/moin/WebFrameworks is not the task. It requires
>> some organization and somewhat a selection process in addition to good
>> (probably existing) code v0.1xxx material. I think it would not be
>> overly complex. Both, a new cgi and possibly included snake "rails" (vs
>> "oil")
> 
> Oil is deprecated anyway. :) I'll see if I can find my way into the SIG. 
> And - yes - adding another framework will surely not help us out of the 
> divergence. The more frameworks there are the more people seem to feel 
> urged to say "heck, it will be easier to write my own framework than 
> evaluate all 30 packages on that page".
> 
>  Christoph