• Advertisement
Sign in to follow this  
  • entries
    45
  • comments
    115
  • views
    54824

My Python Web Development rant

Sign in to follow this  

264 views

The Web Special Interest Group for Python has disappointed me lately. Their job is to improve the Python standard library to make it more suitable for web-related development, but sadly the only people who are doing anything seem to be entirely biased towards their own preconceptions of what 'web development' means and are more interested in helping each other than in helping the language as a whole.

Basically, the current proposal seeks to develop some sort of standard that allows current web frameworks to be portable across different web servers (typically IIS, Apache, and native Python ones). They've made it quite clear that they're not interested in the needs of anyone who's not developing a framework and that the rest of us should just pick a framework that we like and hope it gets ported to their proposed standard soon, so that we are blessed with the ability to run it on any platform. (As if there were a lot of web platforms already.)

They've also made it quite clear that they idolise the Java Servlet model of web development, which itself is an order of magnitude more complex than ASP or PHP. Yet they've also made it quite clear that they're unwilling to implement standardised support for sessions, handling form data, query strings, and so on. In other words, they're seeking to bring all the complexity of Java Servlets into Python with none of the (few) benefits of the servlet libraries. Wonderful.

There was a lot of talk of politics, and I quote; "But, how will you obtain the endorsement of the Web-SIG? Keep in mind that a lot of the people actually doing any work on the Web-SIG are authors of existing frameworks, which means to get buy-in you have to support their goals." In other words, they didn't care if my suggestions would help the language or the wider community - they wouldn't be likely to back anything that didn't help them directly, and since developing web frameworks for Python was something pretty much everyone there had already done, making things simpler was of no interest to them.

There are various arguments for expecting the complex servlet-style development. Some say it has higher performance than the ASP/PHP model. Others will say that the class/object model is more maintainable than the script-per-page model. But I can't help thinking that the Python community is missing out here. ASP is predominantly a Microsoft technology and PHP is an ugly C/Perl hybrid. Python fits neatly into that gap - as readable as VB/VBScript, as open and free as PHP. It could be the next big thing for web development, but I don't think the community will let it.
Sign in to follow this  


2 Comments


Recommended Comments

Would you mind providing some more information about your own ideas? Like you, I think that the "sweet spot" is somewhere in between the script-per-page and object approaches of PHP/ASP and JSP respectively. Plus, I'm always interested in rocking the boat.

PM or email if you consider those vehicles more appropriate. Thanks.

Share this comment


Link to comment
I've not thought too deeply about the issue because although I'd love to see change, but it became quite obvious that there wasn't much support for what I was doing.

My deliberately vague proposals can be summed up as:

- Bypass the current expectancy for middleware and frameworks and provide a simple web development package as part of the Python standard library, providing people most of the ease of use of ASP/PHP with all of the power and expressiveness of Python.

- Emulate the Python DB API in providing a standard interface for developers to use, which can be accessed by importing the relevant module. There would be one such module for mod_python, one for cgi, one for IIS, one using the built-in Python HTTPServer, etc.

- Alternatively, clone one of the existing frameworks and make it more portable - my favourite is the mod_python system as it is quite workable even if you ignore all the Apache-specific functionality. Copying that API for a module that runs on IIS would be good. However there would still need to be higher-level functionality layered on top.

- Either way - ensure that at least the following concepts are catered for by a standard module or package of modules: session management/cookies, GET/query string parsing, POST/form parsing, ASP + PHP style templating, text and URL escaping/parsing. Currently this functionality is scattered across standard and non-standard modules, often duplicated.

- Ideally, make these concepts largely orthogonal so that, where necessary, an implementation can provide most of the functionality even where some of it is impossible. For example, a plain CGI implementation of the above may not be able to easily implement persistent sessions, but that doesn't mean there's no benefit to implementing the other aspects for CGI applications.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement