The more I think/understand the way chameleon works the less likely I
think it is going to work.

As I sent out the app engine sdk know includes a modified _ast module
so maybe it will work
(but haven't tried it myself the inclusion was to get genshi working
in the main), but I think the only possibility will be compiling
templates into an in memory cache but unless you have a busy sight the
compile cost might be pretty high, as an app engine will spin down in
less than 30 sec's of non use.  And startup time/spin up time on a new
request will possibly be very expensive unless the template is only
compiled as used and then cached and reused again pretty soon.


On Sun, May 10, 2009 at 9:03 AM, Tim Hoffman <> wrote:
> Or at least it doesn't create .pyc in the file system.
> T
> On Sun, May 10, 2009 at 9:00 AM, Tim Hoffman <> wrote:
>> Hi
>> Just so you know
>> deploying to google app engine won't send pyc files.  App Engine
>> doesn't create pyc files either when running on the service
>> T
>> On Sat, May 9, 2009 at 9:08 PM, Chris McDonough <> wrote:
>>> On 5/9/09 8:50 AM, Malthe Borch wrote:
>>>> As a general improvement (in terms of clarity) and as part of the
>>>> efforts of getting Chameleon working on GAE, I've begun reworking the
>>>> compilation stage.
>>>> If not explicitly disabled (using ``CHAMELEON_CACHE=0``), template
>>>> files (ending in .pt) will be compiled with the result written to a
>>>> Python-module with the same filename (ending in; Python will
>>>> of course attempt to write a byte-code compilation (ending in
>>>> .pt.pyc), which will guarantee good performance when restarting the
>>>> system.
>>>> Then,
>>>> On template instantiation:
>>>> 1) If the ``CHAMELEON_EAGER`` flag is enabled, parse template source
>>>> immediately.
>>>> 2) Load the template source module.
>>>> 3) If the ``CHAMELEON_STATIC`` flag is enabled, compile into
>>>> one-method-fits-all-arguments render methods for main template and
>>>> each available macro (if required).
>>>> On render:
>>>> 4) If the ``CHAMELEON_STATIC`` flag is enabled, collapse
>>>> keyword-arguments into dynamic context (econtext).
>>>> On compilation:
>>>> 5) If the "render call signature" (keyword arguments and macro name)
>>>> matches an already compiled render-method, return it.
>>>> Else:
>>>> 6) Compile template (to source string).
>>>> 7) Append to template source module.
>>>> 8) Reload template source module and return render-method.
>>> I've lost track of what a lot of this means (particularly wrt 
>>> but the stuff I do understand sounds pretty good to me.
>>> At a higher level, let me try to repeat the use case here and tell me if I 
>>> have
>>> it right:
>>> - On template instantiation (at least in eager mode and unless
>>>   CHAMELEON_CACHE=0), a .py file will be written next to the
>>>   template file being instantiated.
>>> - The Chameleon code that actually performs rendering will
>>>   try to find the .py file via some importy sort of thing.
>>> - Python will write the .pyc file.
>>> - When we want to deploy to GAE or other platforms without
>>>   instantiation/compilation support, we'll just check in
>>>   the .py files (or maybe even the .pyc files) and
>>>   push them up.  The instantiation code won't ever need
>>>   to do the compilation step.
>>> Is that close to right?
>>> - C
>>> _______________________________________________
>>> Repoze-dev mailing list
Repoze-dev mailing list

Reply via email to