[Web-SIG] Iterator protocols.

[Alan Kennedy]

Dear Phillip,

OK, now I understand what you're saying about iterators. Sorry for being 
so thick, and thanks for your patience.

More below.

[Alan Kennedy]
 >> I really am confused now by what you say. Is it possible that you're
 >> misunderstanding my approach?

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

[Snip some java code posted by Alan]

[Phillip J. Eby]
 > ...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.

My misunderstanding was based on the fact that I mistakenly thought that 
the application object authors would always implement the 2.2 iterator 
protocol on their own objects, i.e. explicit .__iter__() and .next() 
methods, etc: I forgot that they could just return a simple python 
object, e.g. list, etc, which is of course an iterable as well.

[Phillip J. Eby]
 > .... 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.

Unfortunately not: jython 2.1 does not have such a method in the 
PyObject API. The only iterator related methods in the jython 2.1 
PyObject API are

__getitem__()
__len__()

Jython 2.2alpha does have 2.2 iterator support, i.e. all built-in 
sequence objects implement the 2.2 iterator protocol.

http://cvs.sourceforge.net/viewcvs.py/jython/jython/org/python/core/PyObject.java?rev=2.30&view=log

But jython 2.2 is unfortunately currently out-of-the-question: not 
production quality yet. And it could be a while before it becomes 
production quality. I want to create a robust jython WSGI solution for 
right now.

[Phillip J. Eby]
 > 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).

I see now that that is my only option.

Which is fine, it's not actually that much work. And I would have to do 
some of it for WSGI anyway, due to the requirements relating to 
application objects with __len__ methods, etc.

[Alan Kennedy]
 >> 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.

[Phillip J. Eby]
 > 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?

To me, the whole point of implementing the 2.2 iterator protocol under 
jython 2.1 was so that there is at least a sporting chance that 
third-party WSGI components written for cpython 2.2 will run under my 
2.1 container. I only want to do what I can to make sure that jython is 
not left behind .....

[Phillip J. Eby]
 > 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.

I'm hoping to maximize portability, and to minimize dependencies.

[Phillip J. Eby]
 > 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.

Well, as I mentioned above, I will attempt to explicitly support both 
the old and new iterator protocols.

Do you think other folks developing embedded (i.e. not coded in python) 
frameworks should consider the same?

[Phillip J. Eby]
 > 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.

And framework-specificity is the very thing that I want to avoid most.

Kind regards,

Alan.