[Zope3-dev] Re: revisiting IResult (for in-Zope pipelining)
Gary Poster
gary at zope.com
Mon Apr 16 13:09:50 EDT 2007
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
More information about the Zope3-dev
mailing list