On Apr 16, 2007, at 9:58 AM, Jim Fulton wrote:
On Apr 15, 2007, at 9:51 PM, Gary Poster wrote:
IResult (zope/publisher/http.py, about line 600) has been the
hidden, private, don't-use-it-because-it's-going-away tool with
which you can build pipelines since before Dec. 2005
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
So, as a strawman, I propose that we make a public interface in
zope.publisher called IResult:
"""An iterable that provides the body data of the response.
For simplicity, an adapter to this interface may in fact
any iterable, without needing to strictly have the iterable
(Very minot note, this violates Python docstring style. A multi-
line docscrine should start with a single-line summary followed by
a blank line.
Good point; thanks.
(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. :-)
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.
Zope3-dev mailing list