[Web-SIG] Iterator protocols.

[Alan Kennedy]

Phillip,

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

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 .....

[Alan Kennedy]
 >> 1. Is there something wrong with my approach of defining a
 >> StopIteration exception, and poking it into __builtin__?

[Phillip J. Eby]
 > Yes; it won't work with anything else that pokes its own StopIteration
 > into __builtin__.  This is very fragile; don't do it.

Hmm, I still don't see the problem. I've got complete control of the 
interpreter, since I am instantiating it. So I can guarantee that any 
mods I make will be made before any other code. I think of it as 
specializing the interpreter to have a new exception.

[Alan Kennedy]
 >> 2. Do I need to implement the old pre-2.2 iterator protocol as well?
 >> It had never occurred to me to implement that: I was focussed only on
 >> 2.2 iterators.

[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.

 > If you're writing an application that must work under pre-2.2 Python,
 > you must implement the *old* iterator protocol, and only that protocol.
 > You do not have to implement the new iterator protocol "as well".
 > Implement the old protocol *instead*.

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.

 > Following these guidelines will make your code both "forward" and
 > "backward" compatible, since newer Pythons still recognize the old
 > iterator protocol.

To some degree, my framework *is* the python in this case.

[Alan Kennedy]
 >> While we're on the subject of python 2.2 requisites, it's also trivial
 >> for me to define True and False. Which leaves generators as the only
 >> 2.2 facility I can't do anything about. But since generators are
 >> optional for application/middleware authors, doesn't that mean that
 >> 2.2.2 is not required as the minimum version for framework authors,
 >> only for 2.2-dependent components that are plugged into their framework?

[Phillip J. Eby]
 > Correct.  By the way, there's no need to define True and False either; a
 > server or gateway supporting a pre-2.2.2 version of Python should just
 > use 1 and 0.  The PEP doesn't actually require the use of True and
 > False, it just refers to "true values" and "false values".

I think I'll set them anyway. That way, components running inside my 
framework won't break if they refer to True or False.

Kind regards,

Alan.