We do have code that expects the symbols to be available outside the
function declared.so they will break?
Backwards Compatibility
Changes proposed in this document should be *mostly* backwards compatible
with current versions of Cheetah, Any unforeseen issues could arise from the
use of #from/#import inside of a function expecting those symbols to be
available outside of the function that they're declared in.
On 6/8/09, R. Tyler Ballance <[email protected]> wrote:
>
> I sat down and wrote up a proposal for a change to the #from/#import
> functionality that Tavis and I had discussed with regards to supporting
> both styles of importing we wanted Cheetah to provide.
>
> You can read the fully formatted CHEP #2 document which is in the "next"
> branch currently here: http://urlenco.de/obfqp
>
> Or I've included it below as well (the raw reStructured text)
> --------------------------------------------------------------
>
>
> Abstract
> --------
> This CHEP proposes an update to the way the #import and #from
> directives are handled such that locally scoped imports and
> module-level imports are handled appropriately.
>
>
> Motivation
> ----------
> Currently Cheetah (v2.2.1) provides two different, but mutually exclusive,
> means of importing Python modules with the #from/#import directives. The
> "traditional" handling for #from/#import (hereafter referred to as "module
> imports")
> is that the generated import statements shall all be relocated to
> the top of the generated module's source code, i.e. ::
>
> #import cjson
>
> Hello $cjson.encode([1, 2, 3])
>
>
> Will result in generated module code along the lines of::
>
> import cjson
>
> class Foo(Template):
> def writeBody(self):
> write('Hello ')
> write(cjson.encode([1, 2, 3]))
>
>
> Also currently in Cheetah is the ability to switch off this
> behavior and enable location specific #from/#import handling
> (hereafter referred to as "function imports") in the generated
> code, with this block of Cheetah for example::
>
> #def aFunction(arg)
> #try
> #from hashlib import md5
> #except ImportError
> #from md5 import md5
> #end try
> #return $md5.new(arg).hexdigest()
> #end def
>
> Will result in code generated with everything in
> place such that the Python looks something like::
>
> class Foo(Template):
> def aFunction(self, arg):
> try:
> from hashlib import md5
> except ImportError:
> from md5 import md5
> return md5.new(arg).hexdigest()
>
> These two approaches to handling the #from/#import directives
> are both beneficial for different situations but currently they
> are handled in mutually exclusive code paths and in mutually
> exclusive fashions.
>
> Specification
> -------------
> The change in #from/#import behavior and how these directives
> are handled is all based on context of their use, making the
> #from/#import handling "intelligent". For module imports, the
> "traditional" handling of the #from/#import directives will
> still apply. Whereas function imports will result in inline
> generated import code.
>
> The basic premise of the change proposed by this document is
> that all #from/#import directives contained within a #def/#end def
> closure will result in import statements contained within that
> function block whereas everywhere else the statements will be relocated
> to the top of the generated module code (i.e. the module import)
>
>
> Rationale
> ---------
> The concept of the "function import" was introduced in Cheetah v2.1.0
> and quickly retrofitted to "live" behind a compiler setting due to the
> regressions with older templates or templates that were designed to utilize
> module imports (through heavy #block/#end block use, etc). Through
> discussion
> with Tavis Rudd, this middle ground between the two styles of importing was
> concluded to be the most reasonable solution to providing "pythonic" import
> functionality (i.e. "function import" also known as "inline imports") while
> still providing the ability to have #from/#import directives declared at
> the
> module scope within the template (within the Cheetah templates, markup and
> most
> directives declared within the module scope are placed inside the default
> method).
>
>
> Backwards Compatibility
> -----------------------
> Changes proposed in this document should be *mostly* backwards
> compatible with current versions of Cheetah, Any unforeseen issues
> could arise from the use of #from/#import inside of a function
> expecting those symbols to be available outside of the function
> that they're declared in.
>
>
> Reference Implementation
> ------------------------
> *still in development*
>
> Copyright
> ---------
> This document has been placed in the public domain.
>
>
> --
> -R. Tyler Ballance
> Slide, Inc.
>
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Cheetahtemplate-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
>
>
>
--
Bidegg worlds best auction site
http://bidegg.com
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Cheetahtemplate-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.