| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
this allows maintenance of the "non-standard Sphinx theme"
to remain in one place.
|
| |
|
|
| |
Change-Id: I151a2351a7fadffd99c843e70c1504135a2c56c6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Includes PR https://github.com/zzzeek/mako/pull/26 so [Travis CI passes](https://travis-ci.org/hugovk/mako/builds/329346809). 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.
Change-Id: I624e1d56e79555c579278c7a5b4de9498179ffe9
Pull-request: https://github.com/zzzeek/mako/pull/27
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Pull request courtesy Hugo.
(cherry picked from commit 7e6a1d7822bac275aabb3c1cc90cb67612548127)
Change-Id: I84a302c982f18762d2514c3f840331d1eb3ebcda
|
| |/
|
|
|
| |
Fixes: #271
Change-Id: I88b46cfbdea9eda0b4c478dd97829bee8431ff58
|
| | |
|
| |
|
|
| |
Change-Id: Ida3604885af6266579f6004029527e90944d0967
|
| |
|
|
| |
Change-Id: I7ba06757b36c6694a1415266f78d79436475caa7
|
| |
|
|
|
|
|
| |
The `print` function adds an unwanted `\n` char.
Change-Id: I4e345214352f0925c374145f41be45550da27393
Pull-request: https://github.com/zzzeek/mako/pull/23
|
| |
|
|
| |
Change-Id: Ic586955b3faf41632da794792ecc9ae447a4051e
|
| |
|
|
| |
Change-Id: Ibdfe5b2f2f3d1426921bcadf6740ae065ed0833b
|
| |\ |
|
| | |\
| | |
| | | |
Marked some docstrings as raw strings to address the invalid escape warning on Python 3.6+
|
| | |/
| |
| |
| | |
on Python 3.6+
|
| |\ \
| | |
| | |
| | | |
Spelling fixes
|
| | |/ |
|
| |\ \
| |/
|/|
| | |
Python 3.6 syntax fixes
|
| |/ |
|
| |
|
|
| |
Change-Id: Ifd065e96676fde5429fd3d5f27c59c960e1ac6bb
|
| | |
|
| |
|
|
|
|
|
|
| |
This works like error_handler but is specific to a template
when included in another using the include tag.
Change-Id: Ie5506a8cba42c71519c703eacc82050902b9ceba
Pull-request: https://bitbucket.org/zzzeek/mako/pull-requests/22
|
| |
|
|
| |
Change-Id: Ib357002b0c919ce532c9b67ba40fcee91ba2554c
|
| |
|
|
| |
Change-Id: I05fcaaebe4566093894fc6abdee705c955ec4a09
|
| | |
|
| |
|
|
| |
in 161b1cf57a3777922fd3e05a6e1314386c2a3912
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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 <nish.aravamudan@canonical.com>
|
| | |
|
| | |
|
| |
|
|
|
| |
- upgrade tox file to use py35, coverage, etc.
- add flake8 rules
|
| | |
|
| |
|
|
|
|
| |
changes in pygments formatting; we might be losing
a bit of what was tested here originally but we still assert pygments
is taking place.
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | | |
pr16
|
| | | | |
|
| | | | |
|
| | |/
|/| |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If mako templates contain something like "_('Köln')", babel extractor converts
it to pure ASCII so that resulting .po file would contain "K\xf6ln". Not all
translation tools and translations are ready for such kind of escape sequences.
Babel allows message ids to be non-ascii, the plugin just has to return Unicode
objects instead of ASCII strings (and that's exactly how Babel built-in Python
and JavaScript extractors work).
This fix ensures mako extractor doesn't excape non-ascii symbols, works well
both for Unicode and non-unicode input (there is a test for cp1251 encoding),
and also provides a workaround for babel charset detector python-babel/babel#274.
|
| | | |
|