(#2) Conditionalized #import behavior — Cheetah3 - The Python-Powered Template Engine

# (#2) Conditionalized #import behavior

CHEP: | 2
Title: | Conditionalized #import behavior
Version: | 1
Author: | R Tyler Ballance <tyler at slide.com>
Status: | Draft
Type: | Standards Track
Content-Type: | text/x-rst
Created: | 07-Jun-2009

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