[pypy-dev] Cheetah on PyPy?

Amaury Forgeot d'Arc amauryfa at gmail.com
Wed Feb 6 22:54:42 CET 2013


2013/2/6 Skip Montanaro <skip at pobox.com>

> I'm slowly working through some little tests which don't require and
> of our libraries at work.  My current test is a script which uses the
> Cheetah template engine.  I see that it is buried somewhere in PyPy's
> tests (inside genshi?), but my straightforward install of Cheetah
> 2.4.4 doesn't work because the str() of a compiled template doesn't do
> any of the required template expansion.  It just returns what looks
> suspiciously like the repr() of the object.
>
> Is there a modified version of Cheetah somewhere (or patch) which
> coaxes it to work with PyPy?  Failing that, where is the test suite
> code?  I see no references to it as a standalone download, and am
> currently working with a binary build of 1.9
>

It's due a small incompatibility between CPython and PyPy.

You are right that __str__ is not correctly set on Cheetah templates, this
is because of this statement in Cheetah/Template.py:
    concreteTemplateClass.__str__ is object.__str__
A fix is to replace the "is" operator by "==".
This is correcly covered by the tests in Cheetah/Tests/Template.py (just
run this file with pypy)

The explanation origins from a CPython oddity (IMHO):
CPython has no "unbound built-in methods" for C types, and object.__str__
yields the same object every time.
This is not the case for user-defined classes, for example
"type(help).__repr__ is type(help).__repr__" is False.

PyPy is more regular here, and has real unbound built-in methods. On the
other hand this means that the "is" comparison should not be used, even for
built-in methods.
A similar pattern existed in the stdlib pprint.py, and we chose to fix the
module.

-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130206/90165b6d/attachment-0001.html>


More information about the pypy-dev mailing list