Merge pull request #1087 from pallets/jinja-name

use "Jinja" instead of "Jinja2"

CHANGES.rst

@@ -258,7 +258,7 @@ Released 2017-01-07, codename Derivation
 -   Change the logic for macro autoescaping to be based on the runtime
     autoescaping information at call time instead of macro define time.
 -   Ported a modified version of the ``tojson`` filter from Flask to
-    Jinja2 and hooked it up with the new policy framework.
+    Jinja and hooked it up with the new policy framework.
 -   Block sets are now marked ``safe`` by default.
 -   On Python 2 the asciification of ASCII strings can now be disabled
     with the ``compiler.ascii_str`` policy.
@@ -304,7 +304,7 @@ Released 2015-07-26, codename Replacement
 -   Changed cache keys to use absolute file names if available instead
     of load names.
 -   Fixed loop length calculation for some iterators.
--   Changed how Jinja2 enforces strings to be native strings in Python 2
+-   Changed how Jinja enforces strings to be native strings in Python 2
     to work when people break their default encoding.
 -   Added :func:`make_logging_undefined` which returns an undefined
     object that logs failures into a logger.
@@ -425,12 +425,12 @@ Released 2011-07-24, codename Convolution
     Previously an import suddenly "disappeared" in a scoped block.
 -   Automatically detect newer Python interpreter versions before
     loading code from bytecode caches to prevent segfaults on invalid
-    opcodes. The segfault in earlier Jinja2 versions here was not a
-    Jinja2 bug but a limitation in the underlying Python interpreter. If
-    you notice Jinja2 segfaulting in earlier versions after an upgrade
+    opcodes. The segfault in earlier Jinja versions here was not a
+    Jinja bug but a limitation in the underlying Python interpreter. If
+    you notice Jinja segfaulting in earlier versions after an upgrade
     of the Python interpreter you don't have to upgrade, it's enough to
     flush the bytecode cache. This just no longer makes this necessary,
-    Jinja2 will automatically detect these cases now.
+    Jinja will automatically detect these cases now.
 -   The sum filter can now sum up values by attribute. This is a
     backwards incompatible change. The argument to the filter previously
     was the optional starting index which defaults to zero. This now
@@ -498,7 +498,7 @@ Released 2010-08-17
     than the pluralize count will no longer raise a :exc:`KeyError`.
 -   Removed builtin markup class and switched to markupsafe. For
     backwards compatibility the pure Python implementation still exists
-    but is pulled from markupsafe by the Jinja2 developers. The debug
+    but is pulled from markupsafe by the Jinja developers. The debug
     support went into a separate feature called "debugsupport" and is
     disabled by default because it is only relevant for Python 2.4
 -   Fixed an issue with unary operators having the wrong precedence.
@@ -581,7 +581,7 @@ Version 2.2.1
 
 Released 2009-09-14
 
--   Fixes some smaller problems for Jinja2 on Jython.
+-   Fixes some smaller problems for Jinja on Jython.
 
 
 Version 2.2
@@ -687,4 +687,4 @@ Version 2.0rc1
 
 Released 2008-06-09
 
--   First release of Jinja2
+-   First release of Jinja 2.

docs/api.rst

@@ -3,16 +3,16 @@ API
 
 .. module:: jinja2
     :noindex:
-    :synopsis: public Jinja2 API
+    :synopsis: public Jinja API
 
-This document describes the API to Jinja2 and not the template language.  It
+This document describes the API to Jinja and not the template language.  It
 will be most useful as reference to those implementing the template interface
-to the application and not those who are creating Jinja2 templates.
+to the application and not those who are creating Jinja templates.
 
 Basics
 ------
 
-Jinja2 uses a central object called the template :class:`Environment`.
+Jinja uses a central object called the template :class:`Environment`.
 Instances of this class are used to store the configuration and global objects,
 and are used to load templates from the file system or other locations.
 Even if you are creating templates from strings by using the constructor of
@@ -24,7 +24,7 @@ initialization and use that to load templates.  In some cases however, it's
 useful to have multiple environments side by side, if different configurations
 are in use.
 
-The simplest way to configure Jinja2 to load templates for your application
+The simplest way to configure Jinja to load templates for your application
 looks roughly like this::
 
     from jinja2 import Environment, PackageLoader, select_autoescape
@@ -55,15 +55,15 @@ a lot easier to use it also enables template inheritance.
 
 .. admonition:: Notes on Autoescaping
 
-   In future versions of Jinja2 we might enable autoescaping by default
+   In future versions of Jinja we might enable autoescaping by default
    for security reasons.  As such you are encouraged to explicitly
    configure autoescaping now instead of relying on the default.
 
 
 Unicode
 -------
 
-Jinja2 is using Unicode internally which means that you have to pass Unicode
+Jinja is using Unicode internally which means that you have to pass Unicode
 objects to the render function or bytestrings that only consist of ASCII
 characters.  Additionally newlines are normalized to one end of line
 sequence which is per default UNIX style (``\n``).
@@ -88,24 +88,24 @@ second line of the Python module using the Unicode literal::
 
 We recommend utf-8 as Encoding for Python modules and templates as it's
 possible to represent every Unicode character in utf-8 and because it's
-backwards compatible to ASCII.  For Jinja2 the default encoding of templates
+backwards compatible to ASCII.  For Jinja the default encoding of templates
 is assumed to be utf-8.
 
-It is not possible to use Jinja2 to process non-Unicode data.  The reason
-for this is that Jinja2 uses Unicode already on the language level.  For
-example Jinja2 treats the non-breaking space as valid whitespace inside
+It is not possible to use Jinja to process non-Unicode data.  The reason
+for this is that Jinja uses Unicode already on the language level.  For
+example Jinja treats the non-breaking space as valid whitespace inside
 expressions which requires knowledge of the encoding or operating on an
 Unicode string.
 
 For more details about Unicode in Python have a look at the excellent
 `Unicode documentation`_.
 
-Another important thing is how Jinja2 is handling string literals in
+Another important thing is how Jinja is handling string literals in
 templates.  A naive implementation would be using Unicode strings for
 all string literals but it turned out in the past that this is problematic
 as some libraries are typechecking against `str` explicitly.  For example
 `datetime.strftime` does not accept Unicode arguments.  To not break it
-completely Jinja2 is returning `str` for strings that fit into ASCII and
+completely Jinja is returning `str` for strings that fit into ASCII and
 for everything else `unicode`:
 
 >>> m = Template(u"{% set a, b = 'foo', 'föö' %}").module
@@ -121,8 +121,8 @@ High Level API
 --------------
 
 The high-level API is the API you will use in the application to load and
-render Jinja2 templates.  The :ref:`low-level-api` on the other side is only
-useful if you want to dig deeper into Jinja2 or :ref:`develop extensions
+render Jinja templates.  The :ref:`low-level-api` on the other side is only
+useful if you want to dig deeper into Jinja or :ref:`develop extensions
 <jinja-extensions>`.
 
 .. autoclass:: Environment([options])
@@ -260,7 +260,7 @@ Autoescaping
 
 .. versionchanged:: 2.4
 
-Jinja2 now comes with autoescaping support.  As of Jinja 2.9 the
+Jinja now comes with autoescaping support.  As of Jinja 2.9 the
 autoescape extension is removed and built-in.  However autoescaping is
 not yet enabled by default though this will most likely change in the
 future.  It's recommended to configure a sensible default for
@@ -300,10 +300,8 @@ the `autoescape` block (see :ref:`autoescape-overrides`).
 Notes on Identifiers
 --------------------
 
-Jinja2 uses the regular Python 2.x naming rules.  Valid identifiers have to
-match ``[a-zA-Z_][a-zA-Z0-9_]*``.  As a matter of fact non ASCII characters
-are currently not allowed.  This limitation will probably go away as soon as
-unicode identifiers are fully specified for Python 3.
+Jinja uses Python naming rules. Valid identifiers can be any combination
+of Unicode characters accepted by Python.
 
 Filters and tests are looked up in separate namespaces and have slightly
 modified identifier syntax.  Filters and tests may contain dots to group
@@ -445,11 +443,11 @@ The Context
 .. admonition:: Implementation
 
     Context is immutable for the same reason Python's frame locals are
-    immutable inside functions.  Both Jinja2 and Python are not using the
+    immutable inside functions.  Both Jinja and Python are not using the
     context / frame locals as data storage for variables but only as primary
     data source.
 
-    When a template accesses a variable the template does not define, Jinja2
+    When a template accesses a variable the template does not define, Jinja
     looks up the variable in the context, after that the variable is treated
     as if it was defined in the template.
 
@@ -469,7 +467,7 @@ own loader, subclass :class:`BaseLoader` and override `get_source`.
 .. autoclass:: jinja2.BaseLoader
     :members: get_source, load
 
-Here a list of the builtin loaders Jinja2 provides:
+Here a list of the builtin loaders Jinja provides:
 
 .. autoclass:: jinja2.FileSystemLoader
 
@@ -531,7 +529,7 @@ Builtin bytecode caches:
 Async Support
 -------------
 
-Starting with version 2.9, Jinja2 also supports the Python `async` and
+Starting with version 2.9, Jinja also supports the Python `async` and
 `await` constructs.  As far as template designers go this feature is
 entirely opaque to them however as a developer you should be aware of how
 it's implemented as it influences what type of APIs you can safely expose
@@ -578,7 +576,7 @@ Example::
     env.policies['urlize.rel'] = 'nofollow noopener'
 
 ``compiler.ascii_str``:
-    This boolean controls on Python 2 if Jinja2 should store ASCII only
+    This boolean controls on Python 2 if Jinja should store ASCII only
     literals as bytestring instead of unicode strings.  This used to be
     always enabled for Jinja versions below 2.9 and now can be changed.
     Traditionally it was done this way since some APIs in Python 2 failed
@@ -626,7 +624,7 @@ Utilities
 ---------
 
 These helper functions and classes are useful if you add custom filters or
-functions to a Jinja2 environment.
+functions to a Jinja environment.
 
 .. autofunction:: jinja2.environmentfilter
 
@@ -658,7 +656,7 @@ functions to a Jinja2 environment.
 
 .. admonition:: Note
 
-    The Jinja2 :class:`Markup` class is compatible with at least Pylons and
+    The Jinja :class:`Markup` class is compatible with at least Pylons and
     Genshi.  It's expected that more template engines and framework will pick
     up the `__html__` concept soon.
 
@@ -915,9 +913,9 @@ don't recommend using any of those.
 
 .. admonition:: Note
 
-    The low-level API is fragile.  Future Jinja2 versions will try not to
-    change it in a backwards incompatible way but modifications in the Jinja2
-    core may shine through.  For example if Jinja2 introduces a new AST node
+    The low-level API is fragile.  Future Jinja versions will try not to
+    change it in a backwards incompatible way but modifications in the Jinja
+    core may shine through.  For example if Jinja introduces a new AST node
     in later versions that may be returned by :meth:`~Environment.parse`.
 
 The Meta API

docs/extensions.rst

@@ -3,19 +3,19 @@
 Extensions
 ==========
 
-Jinja2 supports extensions that can add extra filters, tests, globals or even
+Jinja supports extensions that can add extra filters, tests, globals or even
 extend the parser.  The main motivation of extensions is to move often used
 code into a reusable class like adding support for internationalization.
 
 
 Adding Extensions
 -----------------
 
-Extensions are added to the Jinja2 environment at creation time.  Once the
+Extensions are added to the Jinja environment at creation time.  Once the
 environment is created additional extensions cannot be added.  To add an
 extension pass a list of extension classes or import paths to the
 ``extensions`` parameter of the :class:`~jinja2.Environment` constructor.  The following
-example creates a Jinja2 environment with the i18n extension loaded::
+example creates a Jinja environment with the i18n extension loaded::
 
     jinja_env = Environment(extensions=['jinja2.ext.i18n'])
 
@@ -196,7 +196,7 @@ Loop Controls
 **Import name:** ``jinja2.ext.loopcontrols``
 
 This extension adds support for ``break`` and ``continue`` in loops.  After
-enabling, Jinja2 provides those two keywords which work exactly like in
+enabling, Jinja provides those two keywords which work exactly like in
 Python.
 
 .. _with-extension:
@@ -242,13 +242,13 @@ Writing Extensions
 
 .. module:: jinja2.ext
 
-By writing extensions you can add custom tags to Jinja2.  This is a non-trivial
+By writing extensions you can add custom tags to Jinja.  This is a non-trivial
 task and usually not needed as the default tags and expressions cover all
 common use cases.  The i18n extension is a good example of why extensions are
 useful. Another one would be fragment caching.
 
 When writing extensions you have to keep in mind that you are working with the
-Jinja2 template compiler which does not validate the node tree you are passing
+Jinja template compiler which does not validate the node tree you are passing
 to it.  If the AST is malformed you will get all kinds of compiler or runtime
 errors that are horrible to debug.  Always make sure you are using the nodes
 you create correctly.  The API documentation below shows which nodes exist and
@@ -257,7 +257,7 @@ how to use them.
 Example Extension
 ~~~~~~~~~~~~~~~~~
 
-The following example implements a ``cache`` tag for Jinja2 by using the
+The following example implements a ``cache`` tag for Jinja by using the
 `cachelib`_ library:
 
 .. literalinclude:: cache_extension.py
@@ -365,7 +365,7 @@ code objects.  Extensions that provide custom statements can return nodes to
 execute custom Python code.
 
 The list below describes all nodes that are currently available.  The AST may
-change between Jinja2 versions but will stay backwards compatible.
+change between Jinja versions but will stay backwards compatible.
 
 For more information have a look at the repr of :meth:`jinja2.Environment.parse`.
 

docs/faq.rst

@@ -18,7 +18,7 @@ How fast is it?
 We really hate benchmarks especially since they don't reflect much.  The
 performance of a template depends on many factors and you would have to
 benchmark different engines in different situations.  The benchmarks from the
-testsuite show that Jinja2 has a similar performance to `Mako`_ and is between
+testsuite show that Jinja has a similar performance to `Mako`_ and is between
 10 and 20 times faster than Django's template engine or Genshi.  These numbers
 should be taken with tons of salt as the benchmarks that took these numbers
 only test a few performance related situations such as looping.  Generally
@@ -28,12 +28,12 @@ code.
 
 .. _Mako: https://www.makotemplates.org/
 
-How Compatible is Jinja2 with Django?
--------------------------------------
+How Compatible is Jinja with Django?
+------------------------------------
 
-The default syntax of Jinja2 matches Django syntax in many ways.  However
+The default syntax of Jinja matches Django syntax in many ways.  However
 this similarity doesn't mean that you can use a Django template unmodified
-in Jinja2.  For example filter arguments use a function call syntax rather
+in Jinja.  For example filter arguments use a function call syntax rather
 than a colon to separate filter name and arguments.  Additionally the
 extension interface in Jinja is fundamentally different from the Django one
 which means that your custom tags won't work any longer.
@@ -80,7 +80,7 @@ So some amount of logic is required in templates to keep everyone happy.
 And Jinja leaves it pretty much to you how much logic you want to put into
 templates.  There are some restrictions in what you can do and what not.
 
-Jinja2 neither allows you to put arbitrary Python code into templates nor
+Jinja neither allows you to put arbitrary Python code into templates nor
 does it allow all Python expressions.  The operators are limited to the
 most common ones and more advanced expressions such as list comprehensions
 and generator expressions are not supported.  This keeps the template engine
@@ -106,7 +106,7 @@ integers and floats for a table of statistics the template designer can
 omit the escaping because he knows that integers or floats don't contain
 any unsafe parameters.
 
-Additionally Jinja2 is a general purpose template engine and not only used
+Additionally Jinja is a general purpose template engine and not only used
 for HTML/XML generation.  For example you may generate LaTeX, emails,
 CSS, JavaScript, or configuration files.
 
@@ -130,7 +130,7 @@ My tracebacks look weird.  What's happening?
 
 If the debugsupport module is not compiled and you are using a Python
 installation without ctypes (Python 2.4 without ctypes, Jython or Google's
-AppEngine) Jinja2 is unable to provide correct debugging information and
+AppEngine) Jinja is unable to provide correct debugging information and
 the traceback may be incomplete.  There is currently no good workaround
 for Jython or the AppEngine as ctypes is unavailable there and it's not
 possible to use the debugsupport extension.
@@ -150,7 +150,7 @@ Credit for this snippet goes to `Thomas Johansson
 Why is there no Python 2.3/2.4/2.5/2.6/3.1/3.2/3.3 support?
 -----------------------------------------------------------
 
-Python 2.3 is missing a lot of features that are used heavily in Jinja2.  This
+Python 2.3 is missing a lot of features that are used heavily in Jinja.  This
 decision was made as with the upcoming Python 2.6 and 3.0 versions it becomes
 harder to maintain the code for older Python versions.  If you really need
 Python 2.3 support you either have to use Jinja 1 or other templating
@@ -160,11 +160,11 @@ Python 2.4/2.5/3.1/3.2 support was removed when we switched to supporting
 Python 2 and 3 by the same sourcecode (without using 2to3). It was required to
 drop support because only Python 2.6/2.7 and >=3.3 support byte and unicode
 literals in a way compatible to each other version. If you really need support
-for older Python 2 (or 3) versions, you can just use Jinja2 2.6.
+for older Python 2 (or 3) versions, you can just use Jinja 2.6.
 
 Python 2.6/3.3 support was dropped because it got dropped in various upstream
 projects (such as wheel or pytest), which would make it difficult to continue
-supporting it. Jinja2 2.10 was the last version supporting Python 2.6/3.3.
+supporting it. Jinja 2.10 was the last version supporting Python 2.6/3.3.
 
 My Macros are overridden by something
 -------------------------------------
@@ -186,7 +186,7 @@ child.tmpl:
     {% macro foo() %}CHILD{% endmacro %}
     {% block body %}{{ foo() }}{% endblock %}
 
-This will print ``LAYOUT`` in Jinja2.  This is a side effect of having
+This will print ``LAYOUT`` in Jinja.  This is a side effect of having
 the parent template evaluated after the child one.  This allows child
 templates passing information to the parent template.  To avoid this
 issue rename the macro or variable in the parent template to have an