Re: [CHEP] Conditionalized #import behavior (#2)

On Mon, Jun 08, 2009 at 01:02:39PM -0700, [email protected] wrote:
>    We do have code that expects the symbols to be available outside the
>    function declared.so they will break?

Yes, if you need imports "globally" available then you should be
#import'ing them in the global scope anyways.

> 
>                             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

-- 
-R. Tyler Ballance
Slide, Inc.

------------------------------------------------------------------------------
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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkotfXwACgkQFCbH3D9R4W/B4wCfSJ/K4oK6TToiOmuMdf7aKxcn
6i4AnRkBY4l2zYBfdO8bnBf7elfzhXGW
=zDOS
-----END PGP SIGNATURE-----