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

[Gary Poster]

On Apr 16, 2007, at 12:30 PM, Philipp von Weitershausen wrote:

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

Well, the IResult interface is different too, but yeah, this should  
be a pretty small job.

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

Yup, agreed.

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

I'd characterize this as a -0 to my "temptation", I suppose.

An over-lunch poll also got no conclusive opinions here one way or  
the other.

I suppose there are four choices: (a) special case strings to make  
sure they are chunked the right way; (b) expect that the adapter  
result will be chunked the right way, so that someone returning a  
string will get bad performance and no error message; (c) puke if  
someone returns a string; or (d) log it to a file, but then do (a).

I really don't like (b).  A string is in fact iterable, so puking, as  
with (c), seems unpleasant.  I'm ok with (d) but it seems excessively  
"naggy".  Strings are *the* common case, so I prefer (a).

I'm more concretely +1 on (a) now that I've spelled out these  
options.  Since no one has given a true -1 on it, I will proceed with  
that, unless we get further discussion.

Gary