As reported upstream in sphinx: https://github.com/sphinx-doc/sphinx/pull/2396

It was a structural change in sphinx-1.4. I'm not sure if this is the proper fix, but it does let the doc build pass, in my testing.

Originally reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830178.

Signed-off-by: Nishanth Aravamudan [email protected]

I'm experimenting with adding Mako support to coverage.py. In order to fully parse the generated Python files to correlate generated lines with source lines, I've added more comment output to identify the lines that aren't associated with any source line.

This is probably not all the places that need to be commented, but seems to work well for the templates I'm using. If you have a better way to do this, or a different way to accomplish the same thing, I'm completely open to other ideas.

They were being correctly parsed already, but a template like this:

<%def name="asdf(*qwert, zxcv='hi')">${zxcv}</%def>

would generate code like this:

def render_asdf(context,*qwert):
    __M_caller = context.caller_stack._push_frame()
    try:
        zxcv = context.get('zxcv', UNDEFINED)
    ...

which would then either TypeError when called with the required keyword argument, or (if there were also a **kwargs) have the argument overwritten by UNDEFINED right out of the gate.

Should work now. Added a few tests. Everything passes on Python 2.7, Python 3.3, and PyPy 2.2.1 (except for two tests that fail PyPy in Beaker somewhere, so not a Mako problem).

Inspired by... mitsuhiko, or python-future, or someone?, I added a compat.py2k, so code can be written as though Python 3 were the default and Python 2 were the special case.

I also made a best effort at the _ast-less code path; four tests fail, but all four of them are problems with how Pygments decided to color the syntax, so I assume that's just an inherent issue with the compiler module. (Two of them are marked as requiring Python 2.5+, so will never run in practice anyway.)

This allows the lexer to correctly handle strings like:

${'backslash quote right-curly is \\\'}'}

And also allows users to use the bitwise-or operator to mean bitwise or simply by enclosing the expression inside parens:

${(0x5432 | 0x8000)}

or by using it in the middle of a dictionary literal:

${ {'foo-val': 0x43 | 0x100, 'bar-val': 0x22 | 0x100}[thing+'-val']}

or inside brackets:

${ big_lookup_dict[index_low | (indexhigh << 3)] }

Basically, only "top level" uses of the vertical bar mean pipe.

(Note that currently, any non-top-level use of the vertical bar in an expression just results in a syntax error in the generated python, so no working code is affected by this change)

• use environment markers - re-enabled universal wheels
• use setuptools_scm for version management (requires semantic version tags [1.0.2]
• stop supporting python 3 < 3.3
• normalize htmlhelp doc name
• remove dead entries from MANIFEST.in

Includes PR https://github.com/zzzeek/mako/pull/26 so Travis CI passes. The last two commits are unique to this PR.

Since Mako 1.0.0, Python 2.6 has been the minimum supported version:

[general] Compatibility changes; in order to modernize the codebase, Mako is now dropping support for Python 2.4 and Python 2.5 altogether. The source base is now targeted at Python 2.6 and forwards.

http://docs.makotemplates.org/en/latest/changelog.html#change-b602a175c0ec26eaa4f42962d23cca96

This removes redundant code only relevant to Python 2.5 or earlier.

It also adds python_requires to setup.py, so pip won't install this version on Python 2.5 or earlier. For people with older versions, pip will install the next Mako version down.

Are all Python 3.x versions supported? If not, I'll add those to python_requires as well.

https://travis-ci.org/mindw/mako/builds/77541154

The following image (svg or png) should be embedded into the readme: https://img.shields.io/travis/zzzeek/mako.svg

I am using mako in shell scripts where the ${}-syntax is already in use by shell variables. So I have to use <%text>-blocks everywhere which is not convinient. This patch provides a way to specifiy an alternate expression syntax, namely double-braces: {{ ... }}.

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

Without this change, when running setup.py extract_messages, we would get error:

TokenError: ('EOF in multi-line statement', (2, 0))

Looking at the unit test, it seems like a literal string argument in the form of "_('xxx')" is supposed to be picked up by Babel. However, that contradicts with the documentation, which states:

When using tags, the values of the arguments are taken as literal strings by default. To embed Python expressions as arguments, use the embedded expression format

So, as a side effect of this commit, the convenience of "_('xxx')" has been removed. Probably can add it back if necessary for backward compatibility.

Starting with 3.6.0, escape sequences in string and byte literals emit a deprecation warning for invalid backslash escapes. This change marks a handful of docstrings as raw strings to address this problem.