- Sep 11, 2013
-
-
Mike Bayer authored
-
mike bayer authored
added arg_stringname function to _ast_util.py
-
Philipp Volugine authored
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
-
- Sep 10, 2013
-
-
Mike Bayer authored
- [bug] Fixed an AST issue that was preventing correct operation under alpha versions of Python 3.4. Pullreq courtesy Zer0-.
-
mike bayer authored
_ast_util.py added visit_NameConstant to SourceGen
-
Philipp Volugine authored
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
-
- Aug 28, 2013
-
-
Mike Bayer authored
- version bump 0.9.1
-
Martin Geisler authored
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.
-
Martin Geisler authored
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.
-
Martin Geisler authored
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.
-
- Aug 04, 2013
-
-
Mike Bayer authored
- other 2.4 ism
-
- Aug 03, 2013
-
-
mike bayer authored
simplify
-
Mike Bayer authored
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]
-
Philip Jenvey authored
-
Mike Bayer authored
interpreted correctly within a template tag. [ticket:190]
-
Mike Bayer authored
skips over module elements that are not explcitly callable, avoiding TypeError when trying to produce partials. [ticket:207]
-
Mike Bayer authored
-
Mike Bayer authored
-
Mike Bayer authored
-
Mike Bayer authored
-
Mike Bayer authored
- guess this is 0.9.0
-
Mike Bayer authored
- add more of a test
-
- Jun 25, 2013
-
-
Yap Sok Ann authored
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.
-
- May 24, 2013
-
-
Mike Bayer authored
if Python version is < 2.6 or is between 3.0 and less than 3.3, as Markupsafe now only supports 2.6->2.X, 3.3->3.X. [ticket:216]
-
- May 19, 2013
-
-
Mike Bayer authored
-
- Apr 15, 2013
-
-
Mike Bayer authored
converted for py3k properly (added tests.) [ticket:214]
-
- Apr 14, 2013
-
-
Mike Bayer authored
file warnings when running the tests under various Pythons with warnings turned on. [ticket:213]
-
Mike Bayer authored
compatible with Py3k. [ticket:212]
-
- Apr 10, 2013
-
-
Mike Bayer authored
-
- Mar 21, 2013
-
-
Mike Bayer authored
so that inheritance chains and includes are located correctly, [ticket:202]
-
Mike Bayer authored
- add gpg sig
-
Mike Bayer authored
-
Mike Bayer authored
-
Mike Bayer authored
-
Xie Shi authored
-
- Feb 21, 2013
-
-
Mike Bayer authored
against a module compiled to the filesystem would fail trying to produce a RichTraceback due to the content being in bytes. [ticket:209]
-
- Feb 15, 2013
-
-
Mike Bayer authored
from tuple to frozenset, as this is expected to be a set by default. [ticket:208]
-
- Dec 21, 2012
-
-
Mike Bayer authored
-
- Nov 25, 2012
-
-
Mike Bayer authored
-
- Nov 12, 2012
-
-
Mike Bayer authored
- fix test_exceptions to always call non-pygments tests - update test for py3k transition
-