[Zope3-dev] revisiting IResult (for in-Zope pipelining)

[Gary Poster]

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

[...]

>> So, as a strawman, I propose that we make a public interface in  
>> zope.publisher called IResult:
>>
>> class IResult(zope.interface.Interface):
>> 	"""An iterable that provides the body data of the response.
>>         For simplicity, an adapter to this interface may in fact  
>> return
>>         any iterable, without needing to strictly have the iterable
>>         provide IResult."""
>
> (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:
>>
>> @zope.interface.implementer(zope.publisher.interfaces.http.IResult)
>> @zope.component.adapter(
>>     SomeCoolLXMLThing,
>>     zope.pubisher.interfaces.browser.IBrowserRequest)
>> def postprocessLXML(lxml, request):
>>     do_some_cool_transformation(lxml)
>>     return output_to_html(lxml)
>
> 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.

Thanks

Gary