[Web-SIG] Iterator protocols.

[Phillip J. Eby]

At 09:45 PM 8/30/04 +0100, Alan Kennedy wrote:
>I really am confused now by what you say. Is it possible that you're 
>misunderstanding my approach?

No; your approach just isn't portable, and breaks the cross-server 
compatibility that's the point of WSGI.  See below.


>I should make it explicitly clear that I am writing this in Java. So when 
>I say I'm iterating over the iterable, I do it this way
>
>//-------------------------------------
>  PyObject iterable = app_result.invoke("__iter__");
>  PyObject next_object = null;
>  while (true)
>   {
>   try
>    { next_object = iterable.invoke("next"); }
>   catch (PyException pe)
>    {
>    // Pseudo-code here
>    if pe is StopIteration: break
>    }
>start_response_callable.write_callable.write(((PyString)next_object).toString());
>   }
>//-------------------------------------
>
>So in light of that .....

...this code won't work if the application returns, say, a list.  But a 
list *would* be a perfectly valid iterable in a "normal" WSGI server or 
gateway; therefore, this approach is broken.

Meanwhile, an application that wants to support running in pre-2.2 
containers *other* than yours, is now forced to implement *both* the old 
and the new protocol!

This is clearly broken, since there's no reason to require 
backward-compatible application code to implement a protocol that isn't 
implemented by the version of Python they're trying to support.


>[Phillip J. Eby]
> > If you're writing a server or gateway, you don't need to implement it at
> > all: use a "for" loop to iterate over the iterable, and all will be well.
>
>Ah, but this sentence only makes sense if I'm writing python/jython: I'm 
>writing java.

Well, perhaps you should check whether there is a Java API you can access 
from Jython that's akin to PyObject_GetIter() in the C API, that's used in 
both Jython 2.1 and Jython 2.2; then your code will be forward and backward 
compatible without implementing both the old and the new protocols.

If there is no such API, and you want to support the 2.2 protocol, you'll 
need to hardcode both the old and new protocols, due to the fact that 
you're not coding in Python (where a simple "for" loop suffices to ensure 
portability).


>To me, the purpose of implementing the 2.2 iterator protocol is so that 
>applications and components run inside my framework will work, if they 
>support the 2.2 iterator protocol. I'm really not interested in the 
>pre-2.2 protocol at all, though I suppose I should be if people want to 
>run pre-2.2 iterable components in my framework.

If a piece of code is written for 2.2 and its iterator protocol, why do you 
think it'll work in your server at all?  It's far more likely that the only 
code you can run in your server will be code written for a 2.1 version of 
Python.  And such code, if it has an iterable at all, is going to be 
written to the old iterator protocol, because it will presumably want to be 
able to run in pre-2.2 CPython containers, too.  So, no matter what, *no* 
code is going to work in your server unless it was specifically written for 
your server: the exact opposite of the point of WSGI.