Previously, they would parse correctly in Python 3, but any keyword-only
arguments would be quietly lost, and the user would either get
`TypeError: foo() got an unexpected keyword argument...` or the
confusing behavior of having the keyword argument overwritten with
whatever's in the context with the same name.

- move CHANGES to changelog.rst

- changelog for pullreq #2

Allow mako-render script to take relative path filenames

This reverts commit 1504fc60.

There's no reason an intervening node should clear the translator
comments.  There's already logic that discards the comments if they
occurred too far away from the harvested string.  This way we can write
more natural templates and still have the translator comments that
provide the best translated text.

http://www.makotemplates.org/trac/ticket/225

- this fixes a bug in the mako-render script which refuses to process a filename
  that is given as a relative path

- try to get all our CSS in one place and above RTD so we get all their styles...

- fix test to work under py3.2

Fixed TGPlugin.render method to support unicode template names in py2k.

  which looked like "#*" from being correctly parsed.  [ticket:224]

Using compat.string_types instead of "str if compat.py3k else basestring" in TGPlugin.render method.

added arg_stringname function to _ast_util.py

This is to be compatible with python3.4 where kwarg and vararg
objects are _ast.arg as opposed to Name objects in earlier versions.
The _ast.arg object cannot be implicitly converted to a string. This
lead to 4 errors in the test suite.

As of this commit all tests pass under python3.4a2

- [bug] Fixed an AST issue that was preventing correct operation
  under alpha versions of Python 3.4.  Pullreq courtesy Zer0-.

_ast_util.py added visit_NameConstant to SourceGen

SourceGenerator didn't work with python3.4 alpha,
`None` Is now a NameConstant rather than a Name in ast
the new method deals with converting it to a string

- version bump 0.9.1

The UTF-8 FAQ says this is the correct name for the encoding.

  http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

  The official name and spelling of this encoding is UTF-8, where UTF
  stands for UCS Transformation Format. Please do not write UTF-8 in
  any documentation text in other ways (such as utf8 or UTF_8), unless
  of course you refer to a variable name and not the encoding itself.

Emacs doesn't recognize "utf8" as a valid coding system. The correct
name is "utf-8". This is in line with the UTF-8 FAQ:

  http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

  The official name and spelling of this encoding is UTF-8, where UTF
  stands for UCS Transformation Format. Please do not write UTF-8 in
  any documentation text in other ways (such as utf8 or UTF_8), unless
  of course you refer to a variable name and not the encoding itself.

Using "-*- encoding:utf-8 -*-" doesn't really set the file encoding
for Emacs. It will even prompt the user when opening a compiled file:

  The local variables list in foo.mak.py
  contains values that may not be safe (*).

  Do you want to apply it?  You can type
  y  -- to apply the local variables list.
  n  -- to ignore the local variables list.

  !  -- to apply the local variables list, and permanently mark these
        values (*) as safe (in the future, they will be set automatically.)

    * encoding: utf-8

The problem is that Emacs looks for a file variable named "coding" and
it doesn't know about "encoding":

  http://www.gnu.org/software/emacs/manual/html_node/emacs/Specify-Coding.html

This is no doubt why Python recognizes "coding:" by itself:

  http://www.python.org/dev/peps/pep-0263/

This change makes the code generator output "# -*- coding:%s -*-" and
updates the documentation and examples to match this style.

- other 2.4 ism

simplify

  method, as this method has a specific internal use. The purpose
  of Context.kwargs has been clarified, in that it only delivers
  top level keyword arguments originally passed to template.render().
  [ticket:219]