[Python-ideas] A Continuations Compromise in Python

John Graham john.a.graham at gmail.com
Tue May 5 02:29:24 CEST 2009


On Mon, May 4, 2009 at 6:24 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> John Graham wrote:
>>
>> True, but similar to ABC's, if each of your major users (i.e.
>> frameworks) ends up reinventing a incompatible wheel, when is it time
>> to try and come up with some small standard they can all share?
>
> Maybe I'm missing something, but I don't see how a
> stateless web server would make use of any kind of
> continuation-invoking mechanism.
>
> The main loop of such a server just gets a request,
> maps the url to a function, and then calls that
> function with parameters from the query string.
> The function does its thing and returns some
> html to send back to the browser.
>
> It has no idea which function should be called
> next, because there's no "next" in a stateless
> server -- it depends entirely on what the user
> of the browser does from there.
>
> Another way of thinking about this is that the
> continuation is encoded in the html form that the
> function returns. So the main loop of the server,
> together with the browser+user, can be thought of
> as a kind of trampoline, where the "function" you
> return isn't a Python function at all, but a form
> whose "submit" button sends a query that results
> in the desired function being called.
>
> It seems to me that the existing Python language
> is perfectly adequate for expressing this.
>
> --
> Greg
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>

I believe it would be used for state that is not transferred via the
URL, such as a user's session with the server should some sort of
persistence take place.



More information about the Python-ideas mailing list