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. T On Sun, May 10, 2009 at 9:03 AM, Tim Hoffman <t...@zute.net> 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 <t...@zute.net> 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 <chr...@plope.com> 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 .pt.py); 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 >>> CHAMELEON_STATIC) >>> 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@lists.repoze.org >>> http://lists.repoze.org/listinfo/repoze-dev >>> >> > _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
