Gary Poster wrote:
Can we quickly figure out a reasonable way to make the new, improved
interface ready for 3.4?
I don't know if it is too late for 3.4.
With the schedule Christian mentioned, it seems like it would be
possible. As you point out later, it doesn't make a huge difference to
me practically because of the new egg distribution story. That said, if
it made it to 3.4 in might encourage more exploration of the pipelining.
It looks like the change is mostly mechanical for now (moving IResult to
a more prominent place).
(I don't define __iter__ explicitly since I've been reminded too many
times that __getitem__ is still a workable iteration protocol.)
I don't agree. Support by Python for __getitem__-based iteration is
for backward compatibility. New code should not use __getitem__, but
should use __iter__/next. It would be clearer IMO to include __iter__
in the interface.
Great by me. :-)
+1 to __iter__ as already mentioned in my other email.
Then we look up the IResult using the same multiadaptation of
(result, request) we have now, which makes it possible to set headers
in the adapter if desired.
An IResult adapter could then be as simple as this:
def postprocessLXML(lxml, request):
Assuming that output_to_html returns a string, we should not encourage
this unless we say that the publisher is going to special-case strings
to iterate over them efficiently.
I'm tempted to do this (i.e., special-case strings). I might talk with
you about this off-line.
I wouldn't mind keeping the IResult API WSGI-ish, meaning that you would
have to return [output_to_html(lxml)] to make the above efficient, or
chunk the strings and yield them.
http://worldcookery.com -- Professional Zope documentation and training
Zope3-dev mailing list