Chameleon: TypeError: 'dict' object is not callable

Hey there,

Recently, we've experienced multiple instances of broken Chameleon templates, causing mostly this type of error:

  File "/home/zope/eggs/Chameleon-2.25-py2.7.egg/chameleon/", line 171, in render
    self._render(stream, econtext, rcontext)
  File "/home/zope/......../var/chameleon-cache/", line 89, in render
    __iterator = _static_140420322122128(getitem('view'), econtext, True, ('rsslinks', ))
TypeError: 'dict' object is not callable

See full traceback here:

The error can usually be eliminated by restarting the affected ZEO-client. It usually only affects one ZEO-client at a time.

I do not understand the problem at this point and I'm wondering if anyone has experienced a similar problem. We've actually seen this problem on multiple Plone installations, where the custom code is very different apart from the Chameleon integration and Plone itself.

Python 2.7.10 mostly
Plone 4.3.x (4.3.4; 4.3.15)
Chameleon 2.25 ; 3.1 2.2.4
We have the problem on multiple deployments which do not have the same versions.

Background / Configuration:
At 4teamwork, we're using Chameleon in 200+ Plone 4 deployments, since about a year now. We use our own configuration layer, ftw.chameleon, allowing us to ship default behavior and opinionated customizations for all our deployments.

We especially want to make sure that all templates are compiled and loaded on boot up time [1]. Chameleon allows to set the CHAMELEON_EAGER environment variable for doing that, but it did not do what we wanted when combined with
That's why we do our own precooking at boot time, executed in a separate thread in parallel:

We've configured Chameleon to use a shared cache directory for all ZEO clients in the buildout.

At the moment our suspicion is that the problem is caused when multiple processes are started more or less at the same time and may end up precompiling the same template at the same time. They will calculate the same file hash and therefore probably replace the file of the other process.
It seems thought that the Chameleon loader is implemented safe enough (writing to a tempfile, then renaming; acquiring the imp-lock around writing, byte-compiling and importing).

So: did someone have such a problem already and can give me a pointer where to dig?


[1] This allows us to have smoother deployments, reducing errors for visitors when doing a zero-downtime-deployment.

I think is better that you create an issue on Chameleon's issue tracker.

Ok, thanks. I suspect that our integration is the problem and that it is not a bug in Chameleon itself. That's why I tried to find out if we are the only ones having such issues.

1 Like