rtyler / cheetah Goto Github PK

Hey,
is this repo still maintained? I amconsidering submitting a pull request to fix a bug

I'm stuck with using a somewhat older version of python (2.4) for development, and have run into an issue building the cheetah package. In the C version of _namemapper.c, cheetah uses the PyUnicode_FromFormat function. While this is fine for python version 3.0+, this function doesn't appear anywhere in the python C API documentation for the 2.x versions. It is, however, present in the C API starting in at least 2.6 for some reason.

This appears to be the only thing holding cheetah back from being compatible with 2.4. The fix is trivial, and I've got a patch if you'd like it.

Per "Tuju's" usecase, need a #compiler-setting or some attribute that can be set per-template to allow for setting the class name of a pre-compiled template

There are 6 failures which are line endings tests. Python 2.7
changed the behaviour of the compile() builtin (change documented
at http://docs.python.org/dev/whatsnew/2.7.html). The following
minimally reproduces the change:

c = compile('x="""\r\nx\r\n"""', 'file', 'exec')
exec(c, globals(), locals())

print x == "\nx\n"

Under 2.7 this prints "True". Under earlier versions of python, it prints
"False".

I can't see a way round this short of replacing all in-string literal
newlines
with "\r\n" or "\r". This would require pre-parsing the template to find
the strings. Hopefully there's a nicer way.

Here, we don't actually care that literal line endings get converted to UNIX
line endings; does this matter to anyone? Would it be easier to require
non-UNIX line endings to be escaped?

_namemapper.c:PyNamemapper_valueForName calls PyObject_GetAttrString and doesn't check its return value for NULL. It does check PyErr_Occurred(), but that isn't being triggered in this case (which looks like a bug in the python c api -- I was getting this sporadically on a live service running python 2.4.6).

It should be checking for NULL as well and setting a python error and returning NULL in that case.

We worked around this by overriding getattr instead of getattribute (which should have been done in the first place), but the python issue, not protected against by cheetah, is still there.

These two files class on Mac OSX HFS volumes:

find . -name \*.h
./cheetah/c/cheetah.h
./cheetah/c/Cheetah.h

Hi! First I got the problem with Cheetah 2.4.2 in Debian 6.0, but it seems latest Cheetah 2.4.4 has the same bug (if it's a bug and not an error on my side). I narrowed the problem to the following code in Compiler.py, line 1476:

def attributes(self):
    attribs = [self.setting('indentationStep') + str(attrib)
                  for attrib in self._generatedAttribs ]
    return '\n\n'.join(attribs)

The problem is in str(attrib) - if attrib is non-ascii unicode (I don't know how Cheetah works but it seems it converts the entire source to unicode) then str(attrib) fails. I cannot even compile the following simple template:

#encoding utf-8
#attr $test = 'тест' # this is 'test' in Russian

See:

$ cheetah compile test.tmpl
Compiling test.tmpl -> test.py
Traceback (most recent call last):
        ...
      File "/usr/lib/pymodules/python2.6/Cheetah/Compiler.py", line 1478, in attributes for attrib in self._generatedAttribs ]
UnicodeEncodeError: 'ascii' codec can't encode characters in position 8-11: ordinal not in range(128)