On Jun 12, 5:10 am, dbrattli <dbrat
...@gmail.com> wrote:
> GearShift,
http://code.google.com/p/python-gearshift/exposes
> templates similar to TurboGears, but the @expose has been rewritten as
> a (before_finalize) CP tool, thus I can use them as decorators etc
> without having to wrap the handler.
> But now in 3.2 (trunk) I see that tools.encode is wrapping the
> handler. A GearShift/TurboGears handler usually returns a dict and
> right now tools.encode turns this dict into a list of keys. Thus my
> Genshi template engine gets a list of keys instead of the dict it's
> expecting. So I have to turn off tools.encode to get things working.
> But then I need to force an encoding from Genshi since I cannot use
> tools.encode anymore.
> I guess there's a good reason for turning tools.encode into a
> (before_handler) tool that wraps the handler, but it makes it much
> harder to write tools that processes various output from the handlers
> that is not strings. That was the real advantage of using tools. I do
> want output encoding, so this means that I will have to rewrite all my
> before_finalize tools to become before_handler tools and then wrap the
> handler myself (before tools.encode). I think I would prefer
> tools.encode was done a bit later (before_finalize) as before.
Yes, it's always been a design flaw. Handlers were always meant to
return strings or iterables of strings only. Previous versions of
CherryPy were lax in this requirement, which allowed handlers to
return other things (such as dicts, as you have done), so that
response.body could be theoretically any type between the handler()
call and the finalize() call. Unfortunately, other types break Tools
which have abided by the (loosely-specified and loosely-enforced)
contract that response.body be a string or iterable of strings.
This became even more dangerous in the python3 branch, because byte
strings and unicode are no longer interchangeable nor automatically
coerce from one to the other. Rather than burden Tools with the
additional requirement to distinguish between bytes and unicode (and
most likely coerce back and forth a lot, slowing things down), I
decided to limit response.body even more: in 3.2 it must now be a
bytestring or iterable of bytestrings. In order to allow folks to
return unicode from handlers, therefore, tools.encoding had to move
and wrap the handler.
I'm sorry about the extra work required to change existing Tools. But
I think the few extra lines of code are outweighed by the interop
benefits of turning on any Tool you got from anywhere, without having
to worry about how it will interact with your custom response.body
return type.
More discussion welcome.
Robert Brewer
fuman...@aminus.org
|
