Christoph Haas wrote: > I have just subscribed to this list and while I waded through a few > postings in the list's archive I might not have a clear picture of what's > currently really going on. So I may ask about things that you have decided > on already.
I've just resubscribed after a while, mainly because I think your proposal is interesting and provides a dimension that was originally considered in the establishment of this mailing list, but which has been lost over time. > Frankly I'm unhappy with the 'cgi' module in the standard library. A > posting on the python-user mailing list made me rethink why web > programming is so painful for me in Python while it was easy in Perl > (while everything else was hard in Perl which is easy in Python). IMHO > Python deserves at least a good CGI implementation. And since I'm used to > Perl's 'CGI' module I would at least expect the same functionality in > Python. While your focus is on the cgi module, and it may be the case that you're specifically interested in CGI as an execution model (with standard input, output, environment variables, and so on), I interpret your sentiments more broadly as a desire for a simple API which works with CGI and other technologies, and where the style of programming is as transparent as old-fashioned CGI scripts: you can clearly see how the program gets its inputs, makes its decisions, and then produces its output. Am I right in thinking this? If so, then you've found at least one other person who thinks there should be a fairly reasonable and obvious foundation for Web programming in the standard library, where "obvious" means an API which deals with high-level concepts familiar to Web programmers in other communities, and where "reasonable" means that you don't have to run some highly specific server solution to use it. Of course, there are arguments against advancing the standard library in this way, mostly expressing the sentiment that if you want things to be easy, you should be using a megaframework. But whilst some people have advocated the use of Django (for example), and whilst frameworks like Django provide a fairly reasonable API at some level, there are good reasons for not launching newcomers towards megaframeworks at the first opportunity. First of all, it makes Python itself difficult to advocate: "Use Python for Web programming? Batteries not included? You mean I have to choose from this list?" Secondly, the megaframeworks often have a confusing message: the Django tutorial goes off into creating database models at the very start, for example - something thankfully rectified in the draft Django book - and this doesn't appeal to people wanting to start simple and get "hello world" or "hello form data" up and running. Thirdly, it means that lots of different groups are doing things their own way when they don't have to; whilst WSGI reduces this, the phenomenon persists at the API level. And I think the API level is critical because that's what programmers relate to. As long as they can have some flexibility in the way they deploy their code, and as long as they don't have to spend a day just configuring servers before they can get started, that aspect isn't interesting at the earliest stage of exploration. Instead, people want to know what the code has to look like, whether they can stomach writing it that way, and whether there's anything out there to make it more pleasant to work with when doing common things like outputting forms. That web.py came along even after the most prominent megaframeworks made their entrance says a lot about the demand for simplicity and transparency in some quarters. [...] > Should I just go ahead and create yet another framework and increase the > chaos by joining the dark side? Or is there work going on where my ideas > would fit in and where my revolutionary energy saves the world? Probably against all other advice you're going to get, I'd recommend that you look at WebStack, Indra and httpy (all on the WebStandardisation page) and spend less time looking at the frameworks on the WebFrameworks page. What you'll get from WebStack is a sense of what it's like to make something like the Java Servlet API but applicable for anything from CGI to Zope; from Indra you'll see a fair amount of consideration given to the common interfaces needed in a Web framework (with the list of interfaces corresponding somewhat to your long list of desirable features); from httpy you'll see a wrapping around WSGI to make it more obvious to developers outside the WSGI community. Where your revolutionary energy saves the world is where you get to propose something that enters the standard library as a better API everyone can use to further whatever applications or megaframeworks they choose to develop and use. Good luck! Paul _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
