Jinja is a fast, expressive, extensible templating engine.

Overview

Jinja

Jinja is a fast, expressive, extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. Then the template is passed data to render the final document.

It includes:

  • Template inheritance and inclusion.
  • Define and import macros within templates.
  • HTML templates can use autoescaping to prevent XSS from untrusted user input.
  • A sandboxed environment can safely render untrusted templates.
  • AsyncIO support for generating templates and calling async functions.
  • I18N support with Babel.
  • Templates are compiled to optimized Python code just-in-time and cached, or can be compiled ahead-of-time.
  • Exceptions point to the correct line in templates to make debugging easier.
  • Extensible filters, tests, functions, and even syntax.

Jinja's philosophy is that while application logic belongs in Python if possible, it shouldn't make the template designer's job difficult by restricting functionality too much.

Installing

Install and update using pip:

$ pip install -U Jinja2

In A Nutshell

{% extends "base.html" %}
{% block title %}Members{% endblock %}
{% block content %}
  <ul>
  {% for user in users %}
    <li><a href="{{ user.url }}">{{ user.username }}a>li>
  {% endfor %}
  ul>
{% endblock %}

Links

Issues
  • 2.9 regression when assigning a variable inside a loop

    2.9 regression when assigning a variable inside a loop

    2.9:

    >>> jinja2.Template('{% set a = -1 %}{% for x in range(5) %}[{{ a }}:{% set a = x %}{{ a }}] {% endfor %}{{ a }}').render()
    u'[:0] [:1] [:2] [:3] [:4] -1'
    

    2.8:

    >>> jinja2.Template('{% set a = -1 %}{% for x in range(5) %}[{{ a }}:{% set a = x %}{{ a }}] {% endfor %}{{ a }}').render()
    u'[-1:0] [0:1] [1:2] [2:3] [3:4] -1'
    

    Originally reported on IRC:

    A change in jinja2 scoping appears to affect me, and I'm unsure of the correct fix. Specifically the problem is the assignment of year here: https://github.com/kennethlove/alex-gaynor-blog-design/blob/551172/templates/archive.html#L13-L24

    opened by ThiefMaster 65
  • Add support for the Environment to optionally return native types.

    Add support for the Environment to optionally return native types.

    This works by having an alternate CodeGenerator that avoids doing to_string after the yield statement and a new version of concat that handles the returned generator with a bit more "intelligence".

    Related to https://github.com/ansible/ansible/pull/23943

    We use jinja heavily in the ansible project. Although it seems to target a text based destination for the renderers, our users have a desire to preserve the types of their templated vars. We also do a lot of internal intercept and post-processing to preserve those types but it's hit or miss and never obvious to the end user what will work and what won't. Therefore, I'm trying to extend jinja beyond what it's original usecase might have been.

    This is a first pass and I hope to drive discussion with it and shape it into something the rest of the jinja community is happy with.

    opened by jctanner 45
  • Add more strict type tests

    Add more strict type tests

    This PR adds a few more type-related tests.

    • boolean Testing if an object is a boolean required 2 tests.

        {% if result.value is boolean %}
      
    • false Make this similar to testing none value, not requiring sameas

        {% if result.value is false %}
      
    • true Make this similar to testing none value, not requiring sameas

        {% if result.value is true %}
      
    • integer The existing 'number' test does not make a distinction between integer, float or even booleans

        {% if result.value is integer %}
      
    • float The existing 'number' test does not make a distinction between integer, float or even booleans

        {% if result.value is float %}
      
    • ~list~ ~The existing 'sequence' or 'iterable test does not make a distinction between strings, lists or mappings. Even 'iterable' does not help here.~

        {% if result.value is list %}
      

    This brings the same convenience as:

    • none

        {% if result.value is none %}
      
    • string

        {% if result.value is string %}
      
    • mapping

        {% if result.value is mapping %}
      

    For the original Jinja2 use-case where values eventually turn into strings anyway, type-checking is less of an issue, however in Ansible or other projects that use Jinja2 for more than web-templating this is more important.

    We see people turning booleans into strings to compare with 'True' or 'False'. Or doing very weird things to determine what is a string, or a list. If you're not careful you end up with a character, instead of the first element.

    You can see the effect of testing different types in Jinja including these new tests: https://github.com/dagwieers/ansible/blob/jinja2-type-tests/test/integration/targets/jinja2_tests/tasks/main.yml

    PS This PR also has a workaround for a small doc issue breaking Travis testing.

    opened by dagwieers 26
  • Add support for auto-indented blocks

    Add support for auto-indented blocks

    Fixes #178

    Blocks now support a new syntax {%* ... %} that aligns the indentation of multiline string with the block statement itself. This is especially useful when templating YAML or other languages where indentation matters. Example:

    labels.j2:

    tla: webtool
    env: {{ env }}
    

    deployment.yaml.j2:

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      labels:
        {% include 'labels.j2' %}
      name: webtool
    spec:
      selector:
        matchLabels:
          {% include 'labels.j2' %}
      strategy:
        type: Recreate
    

    ...renders to broken YAML:

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      labels:
        tla: webtool
    env: qa
      name: webtool
    spec:
      selector:
        matchLabels:
          tla: webtool
    env: qa
      strategy:
        type: Recreate
    

    deployment_new_syntax.yaml.j2:

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      labels:
        {%* include 'labels.j2' %}
      name: webtool
    spec:
      selector:
        matchLabels:
          {%* include 'labels.j2' %}
      strategy:
        type: Recreate
    

    ...renders correctly:

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      labels:
        tla: webtool
        env: qa
      name: webtool
    spec:
      selector:
        matchLabels:
          tla: webtool
          env: qa
      strategy:
        type: Recreate
    
    opened by tomas-mazak 22
  • jinja2 no longer supports the pytest loader

    jinja2 no longer supports the pytest loader

    Currently, jinja2 expects either _path defined or get_filenames: https://github.com/pallets/jinja/blob/master/src/jinja2/loaders.py#L262-L281

    The pytest assertion rewriter defines neither (see https://github.com/pytest-dev/pytest/blob/master/src/_pytest/assertion/rewrite.py#L48), and as such running a test suite on a source code that has the following global:

    from jinja2 import PackageLoader
    LOADER = PackageLoader(__name__, "templates")
    

    will fail with:

        raise ValueError(
    E   ValueError: The 'xxx' package was not installed in a way that PackageLoader understands.
    

    Not sure if here jinja2 needs to support more ways to get the template rooot, or pytest loader is missing some methods.

    opened by gaborbernat 18
  • Add name and filename to Environment.from_string

    Add name and filename to Environment.from_string

    What do you think about add name and filename parameters in Environment.from_string method ? https://github.com/pallets/jinja/blob/master/jinja2/environment.py#L849

    Something like that:

        def from_string(self, source, name=None, filename=None, globals=None, template_class=None):
            """Load a template from a string.  This parses the source given and
            returns a :class:`Template` object.
            """
            globals = self.make_globals(globals)
            cls = template_class or self.template_class
            return cls.from_code(self, self.compile(source, name=name, filename=filename), globals, None)
    

    Best regards, Stéphane

    opened by harobed 18
  • ImportError: cannot import name 'soft_unicode' from 'markupsafe'

    ImportError: cannot import name 'soft_unicode' from 'markupsafe'

    Description

    Markup has release a new version and now Jinja throws an error.

    File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/dbt/utils.py", line 9, in <module>
        import jinja2
      File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/jinja2/__init__.py", line 12, in <module>
        from .environment import Environment
      File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/jinja2/environment.py", line [25](https://github.com/cloudfactory/edw-dbt/runs/5243038097?check_suite_focus=true#step:7:25), in <module>
        from .defaults import BLOCK_END_STRING
      File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/jinja2/defaults.py", line 3, in <module>
        from .filters import FILTERS as DEFAULT_FILTERS  # noqa: F401
      File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/jinja2/filters.py", line 13, in <module>
        from markupsafe import soft_unicode
    ImportError: cannot import name 'soft_unicode' from 'markupsafe' (/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/markupsafe/__init__.py)
    Error: Process completed with exit code 1.
    

    Bug Replication

    Install Jinja with MarkupSafe 2.1.0

    Expected behavior

    No errors when importing jinja.

    Environment

    • Python version: 3.8.12
    • Jinja version: 2.11.3
    • MarkupSafe: 2.1.0
    opened by sumit-sampang-rai 17
  • Consider adding |items filter

    Consider adding |items filter

    Currently the method of choice to iterate over dictionaries is foo.items() or foo|dictsort. The former requires that the item provided does in fact have an .items method which is sensible to assume in general. The dictsort filter does the same but also sorts.

    In MiniJinja the issue came up that there is no .items implemented there as I did not intend on implementing this method there. In MiniJinja I would prefer to have a |pairs filter. The reason for this is twofold: on the one hand is .items() a Python-ism that shines through, on the other hand does it create this challenge that the same syntax does different things (method access vs item lookup). In Jinja2 this problem has been addressed by changing the order of priority between attribute and item access which requires users to use foo["items"] if they do not want to refer to the method. This has been a source of bugs in the past and as a result I was considering not making the same mistake again.

    At the same time I do not really wish to create some new patterns in MiniJinja if they do not exist in Jinja2 itself.

    My proposal is now to either implement .items() in MiniJinja regardless or to implement |pairs / |items in both. It would effectively just call .items() on the passed value.

    The main benefit would be that it's easier to write templates in a common subset of Jinja2 that works also in languages that are not backed by Python objects.

    Refs https://github.com/mitsuhiko/minijinja/issues/32

    opened by mitsuhiko 17
  • Drop Python 2

    Drop Python 2

    Once this is merged into master, I'll probably release a 3.0.0a1 so people can start testing early.

    • Remove _compat module and other compat code.
    • Run pyupgrade, use f-strings everywhere, replace x and y or z with y if x else z.
    • Remove deprecated code from Jinja 2.x.
    • Stop building universal wheel.
    • Bump bytecode cache version.
    • ~I18N doesn't look for ugettext.~
    • Remove old docs.

    Still have some things left that I'll either hit later or get help with at the PyCascades 2020 sprint:

    • Inline asyncsupport instead of patching where possible. Keep in mind performance reasons for patching.
    • Refactor compiler to extract some helper functions so things like "async for" if self.is_async else "for", Markup if ctx.volatile else str, etc. aren't written by hand all over the place.
    • Use super instead of BaseClass.method where appropriate.
    • Apply pyupgrade and code style fixes to docs.
    • Apply pyupgrade and code style fixes to generated code.
    • Add tests for using Babel for translations.
    opened by davidism 17
  • Unicode NEL character is dropped

    Unicode NEL character is dropped

    Expected Behavior

    When handling a template containing the NEL character, I would expect the rendered result to still contain the character. Maybe I just missed to set an option when creating the template object.

    Actual Behavior

    The NEL character is stripped from the rendered string.

    Minimum Example to Reproduce the Behavior

    from jinja2 import Template
    
    input = '\x85'
    
    template = Template(input)
    output = template.render()
    
    print(input)
    print(input.encode('raw_unicode_escape'))
    print(output)
    print(output.encode('raw_unicode_escape'))
    

    this produces

    …
    b'\x85'
    
    b''
    

    Your Environment

    • Python version: 3.7.2rc1
    • Jinja version: 2.10
    opened by WaitF0r1t 17
  • Decide on a consistent naming of either `Jinja` or `Jinja2`

    Decide on a consistent naming of either `Jinja` or `Jinja2`

    Continuing discussion from https://github.com/pallets/meta/issues/10#issuecomment-209980352

    The naming is inconsistent:

    • Github repo is jinja
    • Pypi package name is jinja2
    • Pallets project calls it "Jinja": https://www.palletsprojects.com/p/jinja/
    • RTD namespace is jinja2.readthedocs.io
    • Pocoo docs (currently the official ones) are "Jinja": http://jinja.pocoo.org/docs/2.9/
    • file extensions are sometimes .jinja, .j2, .jinja2... Ansible project currently uses .j2

    We should pick either "Jinja" or "Jinja2" and use it everywhere for consistency.

    I am open to either, "Jinja" is simpler and shorter, but "Jinja2" has a more distinctive ring to it and less likely to get confused with any other projects.

    opened by jeffwidman 17
  • Lexer improvements

    Lexer improvements

    • fixes #1687 #1688 Additionaly:
    • changes newline_re so that it doesn't have group and doesn't require [::2] after split
    • simplified Tuple[Failure] to Failure
    • used faster isspace instead of regex

    Checklist:

    • [x] Add or update relevant docs, in the docs folder and in code.
    • [x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
    • [x] Add .. versionchanged:: entries in any relevant code docs.
    • [x] Run pre-commit hooks and fix any issues.
    • [x] Run pytest and tox, no tests failed.
    opened by badochov 0
  • `Failure.__call__` provides wrong arguments to `self.error_class`

    `Failure.__call__` provides wrong arguments to `self.error_class`

    filename is provided to name arguments in TemplateSyntaxError in https://github.com/pallets/jinja/blob/7fb13bf94443f067c74204a1aee368fdf0591764/src/jinja2/lexer.py#L264

    Environment:

    • Python version: 3.10
    • Jinja version: 3.2.0.dev
    opened by badochov 0
  • `lexer.Token.value` has wrong type

    `lexer.Token.value` has wrong type

    Type of lexer.Token.value is str but should be t.Any as variable with this type that sometimes is str, sometimes int and sometime float is used for this field in https://github.com/pallets/jinja/blob/7fb13bf94443f067c74204a1aee368fdf0591764/src/jinja2/lexer.py#L665

    Environment:

    • Python version: 3.10
    • Jinja version: 3.2.0dev
    opened by badochov 0
  • Faulty handling of UNC paths

    Faulty handling of UNC paths

    I have a case where Jinja doesn't find a template which is loaded using the PackageLoader("gcovr").

    For reference, see https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd:

    File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?" prefix as detailed in the following sections.

    Using the "\\?\" prefix is desirable in general, because it lifts a few limits, in particular one on the length of the path.

    I haven't gotten to the state where I can present a simple example. My setup is a bit stacked, Jenkins running a job in Kubernetes on Windows, there using Bazel to invoke gcovr to generate a coverage report from some C/C++ binaries compiled with MinGW. What I found there was that Jinja fails to load a style.css file, which is totally there. What I ended up with was that I copied bits'n'pieces from loader.py in order to debug them on that stack in the most crude print() way you can imagine. It's not pretty.

    Still, here's the code from gcovr, which shows how Jinja is integrated:

        from jinja2 import Environment, PackageLoader
    
        return Environment(
            loader=PackageLoader("gcovr"),
            autoescape=True,
            trim_blocks=True,
            lstrip_blocks=True,
        )
    

    And a bit of code that comes from split_template_path() and class PackageLoader:

        template = 'style.css'
        p = os.path.normpath(
            posixpath.join(template_root, *split_template_path(template))
        )
        print(p)
        if not os.path.exists(p):
            print('  -> does not exist')
        elif not os.path.isfile(p):
            print('  -> is not a file')
        else:
            print('  -> is a file')
    
        if os.path.altsep and os.path.altsep in p:
            p = p.replace(os.path.altsep, os.path.sep)
            print(p)
            if not os.path.exists(p):
                print('  -> does not exist')
            elif not os.path.isfile(p):
                print('  -> is not a file')
            else:
                print('  -> is a file')
    

    Locally (running Ubuntu), it works and it doesn't enter the "altsep" path of course. On Windows, it produces this output though:

    \\?\C:\Users\ContainerAdministrator\AppData\Local\Temp\Bazel.runfiles_u_shwwy7\runfiles\gcovr_wheel_5_1_default\gcovr\templates/style.css
      -> does not exist
    \\?\C:\Users\ContainerAdministrator\AppData\Local\Temp\Bazel.runfiles_u_shwwy7\runfiles\gcovr_wheel_5_1_default\gcovr\templates\style.css
      -> is a file
    

    I believe that converting the string-based and rather manual path handling could be improved by using the Python pathlib. I have only gotten to use it recently, but I'm fully convinced that it's a huge step ahead in reliability and readability of code handling paths. As a quick workaround, see the above, i.e. replacing os.path.altsep with os.path.sep in the paths.

    Environment:

    • OS: MS Windows
    • Python version: 3.7
    • Jinja version: 3.1.2
    opened by UlrichEckhardt 8
  • Fix bug involving calling set on a template parameter within all branches of an if block

    Fix bug involving calling set on a template parameter within all branches of an if block

    This fixes a bug where calling {% set %} in all 3 branches of an {% if %} block could result in the parameter being undefined sometimes. If the {% set %} call was not done in all branches or it was done outside of an {% if %} block then the bug would not appear. This was determined to be a bad assumption being made by the ID tracking for variables within the template loader where if the {% set %} occurred in all branches then it was not going to be a previously defined variable.

    Fixes #1253

    Checklist:

    • [x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
    • [x] Add or update relevant docs, in the docs folder and in code.
    • [ ] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
    • [ ] Add .. versionchanged:: entries in any relevant code docs.
    • [x] Run pre-commit hooks and fix any issues.
    • [x] Run pytest and tox, no tests failed.
    opened by kevin-brown 0
  • Add support for namespaces in tuple parsing

    Add support for namespaces in tuple parsing

    This fixes a bug that existed because namespaces within {% set %} were treated as a special case. This special case had the side-effect of bypassing the code which allows for tuples to be assigned to.

    The solution was to make tuple handling (and by extension, primary token handling) aware of namespaces so that namespace tokens can be handled appropriately. This is handled in a backwards-compatible way which ensures that we do not try to parse namespace tokens when we otherwise would be expecting to parse out name tokens with attributes.

    Fixes #1413

    Checklist:

    • [x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
    • [x] Add or update relevant docs, in the docs folder and in code.
    • [x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
    • [x] Add .. versionchanged:: entries in any relevant code docs.
    • [x] Run pre-commit hooks and fix any issues.
    • [x] Run pytest and tox, no tests failed.
    opened by kevin-brown 0
Releases(3.1.2)
  • 3.1.2(Apr 28, 2022)

    This is a fix release for the 3.1.0 feature release.

    • Changes: https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-2
    • Milestone: https://github.com/pallets/jinja/milestone/13?closed=1
    Source code(tar.gz)
    Source code(zip)
  • 3.1.1(Mar 25, 2022)

    • Changes: https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-1
    • Milestone: https://github.com/pallets/jinja/milestone/12?closed=1
    Source code(tar.gz)
    Source code(zip)
  • 3.1.0(Mar 24, 2022)

    This is a feature release, which includes new features and removes previously deprecated features. The 3.1.x branch is now the supported bugfix branch, the 3.0.x branch has become a tag marking the end of support for that branch. We encourage everyone to upgrade, and to use a tool such as pip-tools to pin all dependencies and control upgrades. We also encourage upgrading to MarkupSafe 2.1.1, the latest version at this time.

    • Changes: https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-0
    • Milestone: https://github.com/pallets/jinja/milestone/8?closed=1
    • MarkupSafe changes: https://markupsafe.palletsprojects.com/en/2.1.x/changes/#version-2-1-1
    Source code(tar.gz)
    Source code(zip)
  • 3.0.3(Nov 16, 2021)

  • 3.0.2(Oct 5, 2021)

  • 3.0.1(May 18, 2021)

  • 3.0.0(May 12, 2021)

    New major versions of all the core Pallets libraries, including Jinja 3.0, have been released! :tada:

    • Read the announcement on our blog: https://palletsprojects.com/blog/flask-2-0-released/
    • Read the full list of changes: https://jinja.palletsprojects.com/changes/#version-3-0-0
    • Retweet the announcement on Twitter: https://twitter.com/PalletsTeam/status/1392266507296514048
    • Follow our blog, Twitter, or GitHub to see future announcements.

    This represents a significant amount of work, and there are quite a few changes. Be sure to carefully read the changelog, and use tools such as pip-compile and Dependabot to pin your dependencies and control your updates.

    Source code(tar.gz)
    Source code(zip)
  • 3.0.0rc2(Apr 25, 2021)

  • 3.0.0rc1(Apr 16, 2021)

  • 2.11.3(Jan 31, 2021)

    This contains a fix for a speed issue with the urlize filter. urlize is likely to be called on untrusted user input. For certain inputs some of the regular expressions used to parse the text could take a very long time due to backtracking. As part of the fix, the email matching became slightly stricter. The various speedups apply to urlize in general, not just the specific input cases.

    • PyPI: https://pypi.org/project/Jinja2/2.11.3/
    • Changes: https://jinja.palletsprojects.com/en/2.11.x/changelog/#version-2-11-3
    Source code(tar.gz)
    Source code(zip)
  • 2.11.2(Apr 13, 2020)

  • 2.11.1(Jan 30, 2020)

    This fixes an issue in async environment when indexing the result of an attribute lookup, like {{ data.items[1:] }}.

    • Changes: https://jinja.palletsprojects.com/en/2.11.x/changelog/#version-2-11-1
    Source code(tar.gz)
    Source code(zip)
  • 2.11.0(Jan 29, 2020)

    • Changes: https://jinja.palletsprojects.com/en/2.11.x/changelog/#version-2-11-0
    • Blog: https://palletsprojects.com/blog/jinja-2-11-0-released/
    • Twitter: https://twitter.com/PalletsTeam/status/1221883554537230336

    This is the last version to support Python 2.7 and 3.5. The next version will be Jinja 3.0 and will support Python 3.6 and newer.

    Source code(tar.gz)
    Source code(zip)
  • 2.10.3(Oct 4, 2019)

  • 2.10.2(Oct 4, 2019)

  • 2.10.1(Apr 6, 2019)

    • Changes: https://jinja.palletsprojects.com/en/2.10.x/changelog/#version-2-10-1
    • Blog: https://palletsprojects.com/blog/jinja-2-10-1-released/
    • Twitter: https://twitter.com/PalletsTeam/status/1114605127308992513
    Source code(tar.gz)
    Source code(zip)
  • 2.10(Nov 8, 2017)

    Primary changes

    • A NativeEnvironment that renders Python types instead of strings. http://jinja.pocoo.org/docs/2.10/nativetypes/
    • A namespace object that works with {% set %}. This replaces previous hacks for storing state across iterations or scopes. http://jinja.pocoo.org/docs/2.10/templates/#assignments
    • The loop object now has nextitem and previtem attributes, as well as a changed method, for the common case of outputting something as a value in the loop changes. More complicated cases can use the namespace object. http://jinja.pocoo.org/docs/2.10/templates/#for

    Install or upgrade

    Install from PyPI with pip:

    pip install -U Jinja2
    

    Changelog

    • Added a new extension node called OverlayScope which can be used to create an unoptimized scope that will look up all variables from a derived context.
    • Added an in test that works like the in operator. This can be used in combination with reject and select.
    • Added previtem and nextitem to loop contexts, providing access to the previous/next item in the loop. If such an item does not exist, the value is undefined.
    • Added changed(*values) to loop contexts, providing an easy way of checking whether a value has changed since the last iteration (or rather since the last call of the method)
    • Added a namespace function that creates a special object which allows attribute assignment using the set tag. This can be used to carry data across scopes, e.g. from a loop body to code that comes after the loop.
    • Added a trimmed modifier to {% trans %} to strip linebreaks and surrounding whitespace. Also added a new policy to enable this for all trans blocks.
    • The random filter is no longer incorrectly constant folded and will produce a new random choice each time the template is rendered. (#478)
    • Added a unique filter. (#469)
    • Added min and max filters. (#475)
    • Added tests for all comparison operators: eq, ne, lt, le, gt, ge. (#665)
    • import statement cannot end with a trailing comma. (#617, #618)
    • indent filter will not indent blank lines by default. (#685)
    • Add reverse argument for dictsort filter. (#692)
    • Add a NativeEnvironment that renders templates to native Python types instead of strings. (#708)
    • Added filter support to the block set tag. (#489)
    • tojson filter marks output as safe to match documented behavior. (#718)
    • Resolved a bug where getting debug locals for tracebacks could modify template context.
    • Fixed a bug where having many {% elif ... %} blocks resulted in a "too many levels of indentation" error. These blocks now compile to native elif ..: instead of else: if ..: (#759)
    Source code(tar.gz)
    Source code(zip)
    Jinja2-2.10-py2.py3-none-any.whl(123.41 KB)
    Jinja2-2.10-py2.py3-none-any.whl.asc(488 bytes)
    Jinja2-2.10.tar.gz(255.49 KB)
    Jinja2-2.10.tar.gz.asc(488 bytes)
Simple and extensible administrative interface framework for Flask

Flask-Admin The project was recently moved into its own organization. Please update your references to [email protected]:flask-admin/flask-admin.git. Int

Flask-Admin 5.1k Jul 24, 2022
Simple and extensible administrative interface framework for Flask

Flask-Admin The project was recently moved into its own organization. Please update your references to [email protected]:flask-admin/flask-admin.git. Int

Flask-Admin 4.6k Feb 7, 2021
Extends the Django Admin to include a extensible dashboard and navigation menu

django-admin-tools django-admin-tools is a collection of extensions/tools for the default django administration interface, it includes: a full feature

Django Admin Tools 697 Jul 25, 2022
Drop-in replacement of Django admin comes with lots of goodies, fully extensible with plugin support, pretty UI based on Twitter Bootstrap.

Xadmin Drop-in replacement of Django admin comes with lots of goodies, fully extensible with plugin support, pretty UI based on Twitter Bootstrap. Liv

差沙 4.7k Jul 19, 2022
fastapi-admin is a fast admin dashboard based on FastAPI and TortoiseORM with tabler ui, inspired by Django admin.

fastapi-admin is a fast admin dashboard based on FastAPI and TortoiseORM with tabler ui, inspired by Django admin.

fastapi-admin 1.4k Jul 24, 2022
A simple, elegant Python based web templating engine (part of web.py).

Templator Simple, elegant Python based web templating (part of web.py). If you are familiar with Python, there is no new syntax to learn. This is a st

Dan 1 Dec 13, 2021
ERISHA is a mulitilingual multispeaker expressive speech synthesis framework. It can transfer the expressivity to the speaker's voice for which no expressive speech corpus is available.

ERISHA: Multilingual Multispeaker Expressive Text-to-Speech Library ERISHA is a multilingual multispeaker expressive speech synthesis framework. It ca

Ajinkya Kulkarni 42 Feb 10, 2022
A fast and expressive Craigslist API wrapper

pycraigslist A fast and expressive Craigslist API wrapper. ⚠ As of September 2021, it is believed that Craigslist added a rate-limiter. It is advised

Ira Horecka 17 Jul 22, 2022
Use heroicons in your Django and Jinja templates.

heroicons Use heroicons in your Django and Jinja templates. Requirements Python 3.6 to 3.9 supported. Django 2.2 to 3.2 supported. Are your tests slow

Adam Johnson 37 Jun 10, 2022
Django/Jinja template indenter

DjHTML A pure-Python Django/Jinja template indenter without dependencies. DjHTML is a fully automatic template indenter that works with mixed HTML/CSS

Return to the Source 330 Jul 27, 2022
Simple reuse of partial HTML page templates in the Jinja template language for Python web frameworks.

Jinja Partials Simple reuse of partial HTML page templates in the Jinja template language for Python web frameworks. (There is also a Pyramid/Chameleo

Michael Kennedy 76 Jul 16, 2022
Automatizando a criação de DAGs usando Jinja e YAML

Automatizando a criação de DAGs no Airflow usando Jinja e YAML Arquitetura do Repo: Pastas por contexto de negócio (ex: Marketing, Analytics, HR, etc)

Arthur Henrique Dell' Antonia 5 Oct 19, 2021
HTML Template Linter and Formatter. Use with Django, Jinja, Nunjucks and Handlebars templates.

Find common formatting issues and reformat HTML templates. Django · Jinja · Nunjucks · Handlebars · Mustache · GoLang Ps, --check it out on other temp

Riverside Healthcare Analytics 133 Jul 20, 2022
JTEX is a command line tool (CLI) for rendering LaTeX documents from jinja-style templates.

JTEX JTEX is a command line tool (CLI) for rendering LaTeX documents from jinja-style templates. This package uses Jinja2 as the template engine with

Curvenote 15 Jul 2, 2022
a small, expressive orm -- supports postgresql, mysql and sqlite

peewee Peewee is a simple and small ORM. It has few (but expressive) concepts, making it easy to learn and intuitive to use. a small, expressive ORM p

Charles Leifer 9.3k Jul 22, 2022
a small, expressive orm -- supports postgresql, mysql and sqlite

peewee Peewee is a simple and small ORM. It has few (but expressive) concepts, making it easy to learn and intuitive to use. a small, expressive ORM p

Charles Leifer 9.3k Jul 24, 2022
Expressive Digital Signal Processing (DSP) package for Python

AudioLazy Development Last release PyPI status Real-Time Expressive Digital Signal Processing (DSP) Package for Python! Laziness and object representa

Danilo de Jesus da Silva Bellini 628 Jul 12, 2022
Expressive Digital Signal Processing (DSP) package for Python

AudioLazy Development Last release PyPI status Real-Time Expressive Digital Signal Processing (DSP) Package for Python! Laziness and object representa

Danilo de Jesus da Silva Bellini 573 Feb 8, 2021
Demo programs for the Talking Head Anime from a Single Image 2: More Expressive project.

Demo Code for "Talking Head Anime from a Single Image 2: More Expressive" This repository contains demo programs for the Talking Head Anime

Pramook Khungurn 812 Jul 28, 2022
Code for "Neural Parts: Learning Expressive 3D Shape Abstractions with Invertible Neural Networks", CVPR 2021

Neural Parts: Learning Expressive 3D Shape Abstractions with Invertible Neural Networks This repository contains the code that accompanies our CVPR 20

Despoina Paschalidou 156 Jul 25, 2022
STYLER: Style Factor Modeling with Rapidity and Robustness via Speech Decomposition for Expressive and Controllable Neural Text to Speech

STYLER: Style Factor Modeling with Rapidity and Robustness via Speech Decomposition for Expressive and Controllable Neural Text to Speech Keon Lee, Ky

Keon Lee 103 Jul 21, 2022
Expressive Power of Invariant and Equivaraint Graph Neural Networks (ICLR 2021)

Expressive Power of Invariant and Equivaraint Graph Neural Networks In this repository, we show how to use powerful GNN (2-FGNN) to solve a graph alig

Marc Lelarge 36 Jul 10, 2022
Implementation of "GNNAutoScale: Scalable and Expressive Graph Neural Networks via Historical Embeddings" in PyTorch

PyGAS: Auto-Scaling GNNs in PyG PyGAS is the practical realization of our G NN A uto S cale (GAS) framework, which scales arbitrary message-passing GN

Matthias Fey 124 Jul 27, 2022
A non-custodial oracle and escrow system for the lightning network. Make LN contracts more expressive.

Hodl contracts A non-custodial oracle and escrow system for the lightning network. Make LN contracts more expressive. If you fire it up, be aware: (1)

null 29 Jun 24, 2022
PyTorch Implementation of Daft-Exprt: Robust Prosody Transfer Across Speakers for Expressive Speech Synthesis

Daft-Exprt - PyTorch Implementation PyTorch Implementation of Daft-Exprt: Robust Prosody Transfer Across Speakers for Expressive Speech Synthesis The

Keon Lee 41 Jul 23, 2022
redun aims to be a more expressive and efficient workflow framework

redun yet another redundant workflow engine redun aims to be a more expressive and efficient workflow framework, built on top of the popular Python pr

insitro 337 Jul 17, 2022
Expressive Body Capture: 3D Hands, Face, and Body from a Single Image

Expressive Body Capture: 3D Hands, Face, and Body from a Single Image [Project Page] [Paper] [Supp. Mat.] Table of Contents License Description Fittin

Vassilis Choutas 1.1k Jul 25, 2022
A fast, extensible and spec-compliant Markdown parser in pure Python.

mistletoe mistletoe is a Markdown parser in pure Python, designed to be fast, spec-compliant and fully customizable. Apart from being the fastest Comm

Mi Yu 498 Jul 31, 2022
simplejson is a simple, fast, extensible JSON encoder/decoder for Python

simplejson simplejson is a simple, fast, complete, correct and extensible JSON <http://json.org> encoder and decoder for Python 3.3+ with legacy suppo

null 1.5k Jul 30, 2022