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

Comments
  • 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
  • Test on Python 3.11 production release and 3.12-dev

    Test on Python 3.11 production release and 3.12-dev

    • fixes #

    Checklist:

    • [ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
    • [ ] 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.
    • [ ] Run pre-commit hooks and fix any issues.
    • [ ] Run pytest and tox, no tests failed.
    opened by cclauss 0
  • fix(filter): unique with async generator

    fix(filter): unique with async generator

    unique() filter doesn't work chained after a filter that return an async generator.

    This introduces a async variant of the filter transform the async generator into a list to be able to apply the unique filter.

    Fixes #1781

    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 sileht 2
  • unique filter does not work when chain with a filter that returns async generator

    unique filter does not work when chain with a filter that returns async generator

    unique() filter does not work when chain with a filter that returns async generator

    Environment:

    • Python version: 3.11
    • Jinja version: 3.1.2

    The template:

    {%- set commit_authors = commits | rejectattr("author", "eq", "mergify[bot]") | unique(false, "email_author")| list -%}
    

    The backtrace:

      File "xxxxxx.py", line 2314, in render_template
        return await env.from_string(template).render_async(**infos)
      File "jinja2/environment.py", line 1324, in render_async
        return self.environment.handle_exception()
      File "jinja2/environment.py", line 936, in handle_exception
        raise rewrite_traceback_stack(source=source)
      File "jinja2/environment.py", line 1321, in <listcomp>
        [n async for n in self.root_render_func(ctx)]  # type: ignore
      File "<template>", line 7, in top-level template code
      File "jinja2/async_utils.py", line 65, in auto_await
        return await t.cast("t.Awaitable[V]", value)
      File "jinja2/filters.py", line 1329, in do_list
        return await auto_to_list(value)
      File "jinja2/async_utils.py", line 84, in auto_to_list
        return [x async for x in auto_aiter(value)]
      File "jinja2/async_utils.py", line 84, in <listcomp>
        return [x async for x in auto_aiter(value)]
      File "jinja2/async_utils.py", line 77, in auto_aiter
        for item in t.cast("t.Iterable[V]", iterable):
      File "jinja2/filters.py", line 437, in do_unique
        for item in value:
    TypeError: 'async_generator' object is not iterable
    
    opened by sileht 0
  • Add Environment.extract_parsed_names to support tracking dynamic inheritance or inclusion

    Add Environment.extract_parsed_names to support tracking dynamic inheritance or inclusion

    Add Environment.extract_parsed_names to support tracking dynamic inheritance or inclusion.

    Compared to jinja2.meta.find_referenced_templates(), it:

    a. works on dynamic inheritance and includes b. does not work unless and until you actually render the template

    Many buildsystems are unable to support (b), but some do e.g. [1], the point being that if the target file does not exist, dependency information is not needed since the target file must be built anyway. In such cases, you may prefer this function due to (a).

    [1] https://make.mad-scientist.net/papers/advanced-auto-dependency-generation/

    • fixes #1775

    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 infinity0 1
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.2k Dec 29, 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 731 Dec 28, 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 Dec 31, 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.6k Dec 30, 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 43 Nov 27, 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 24 Dec 28, 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 52 Dec 14, 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 378 Jan 1, 2023
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 106 Dec 28, 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 263 Jan 1, 2023
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 Dec 21, 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 546 Jan 1, 2023
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 Dec 31, 2022
A simple, fast, extensible python library for data validation.

Validr A simple, fast, extensible python library for data validation. Simple and readable schema 10X faster than jsonschema, 40X faster than schematic

kk 209 Sep 19, 2022
A Fast, Extensible Progress Bar for Python and CLI

tqdm tqdm derives from the Arabic word taqaddum (تقدّم) which can mean "progress," and is an abbreviation for "I love you so much" in Spanish (te quie

tqdm developers 23.7k Jan 1, 2023
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 Jan 5, 2023
A minimal, extensible, fast and productive API framework for Python 3.

molten A minimal, extensible, fast and productive API framework for Python 3. Changelog: https://moltenframework.com/changelog.html Community: https:/

Bogdan Popa 980 Nov 28, 2022