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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
