3.2 and tools.encode

[dbrattli]

Hi,

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.

-- Dag

[fumanchu]

On Jun 12, 5:10 am, dbrattli <dbrat...@gmail.com> wrote:
> GearShift,http://code.google.com/p/python-gearshift/exposes

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
fuma...@aminus.org

[dbrattli]

Robert,

I get the point. You are right about keeping response.body encoded.
I'll start fixing my tools.

Thanks,

-- Dag

> fuman...@aminus.org