Skip to content

1.4.0

Choose a tag to compare

View all tags
@sqla-tester sqla-tester released this 04 Aug 18:20
· 4 commits to main since this release
rel_1_4_0
94f84e3

1.4.0

Released: Tue Aug 4 2026

changed

  • [changed] [examples] The examples/bench folder has been removed as it used mostly
    long-obsolete template engines. The examples/wsgi/run_wsgi.py example
    has been updated to remove the use of the removed-in-Python-3.13 cgi
    module, and to be runnable as a module from the project root.

  • [changed] [installation] Minimum MarkupSafe dependency version bumped from 0.9.2 to 2.0.

  • [changed] [tests] The test suite now runs via nox. The old tox.ini remains however nox will
    be the only system that's maintained.

  • [changed] [installation] Project metadata has been migrated to PEP 621 pyproject.toml-based
    configuration. setup.cfg remains only for the [mako_testing]
    section used by Mako's own test suite. The build requirements
    now set the minimum setuptools version at 77.0.0 in order to build Mako
    from source.

  • [changed] [installation] Minimum Python version is now 3.10. Mako 1.4.0 has been tested up through
    Python 3.15.0b4.

bug

  • [bug] [ext] The minimum Lingua version supported by LinguaMakoExtractor is
    now 4.16. The test suite had continued to pin Lingua below 4 long after
    the extractor itself was repaired to work with Lingua 4 in version 1.2.0,
    with the result that the plugin was no longer covered by tests at all; the
    pinned version additionally imports pkg_resources at startup, which is
    not present in current setuptools releases and left the package
    unimportable. Lingua 4.16 resolves entry points using
    importlib.metadata, so no deprecated pkg_resources usage remains.

    References: #393

  • [bug] [exceptions] Fixed issue where formatting a traceback for an exception raised inside a
    template compiled from a string would emit DeprecationWarning: Module globals is missing a __spec__.loader on Python 3.15. Modules for such
    templates were created without a module spec, which Python's
    linecache module consults for every frame while a traceback is
    being built; the warning was raised from within traceback formatting
    itself, disrupting the error report for applications that configure
    warnings as errors. These modules are now given a spec with a loader that
    provides the generated module source, which additionally allows the
    generated source lines to be displayed in tracebacks produced by the
    standard library where previously no source was available.

    References: #437

  • [bug] [exceptions] A series of fixes involving syntax warnings and exceptions found
    during template lexing / compilation:

    -   Warnings raised while a template is compiled, which in practice means
    `SyntaxWarning`, now report the filename and line number of the
    template rather than a line within the generated module, and are no
    longer reported twice.  This applies equally to templates compiled from a
    string, from a file, and to a module file in a
    `Template.module_directory`, as does a warning raised while
    the module level code of a `<%! %>` block runs.  Warnings raised while
    a template renders continue to report the location within the generated
    module.
    
    To do this, Mako replaces `warnings.showwarning` while a template is
    compiled.  As that name is global to the process, an unrelated warning
    displayed by another thread during that window may also be passed through
    Mako's hook, which shows any warning it does not recognize unchanged.
    ([#430](https://github.com/sqlalchemy/mako/issues/430))

-   The `SyntaxException` raised for a syntax error in Python code spanning
    several lines of a template, such as that within a `<% %>` or `<%! %>`
    block, is now reported against the line the error is on, rather than
    against the line on which the block begins.  The line reported for code
    that occupies a single line, such as an expression or a control line, is
    unchanged. ([#245](https://github.com/sqlalchemy/mako/issues/245))

-   The `SyntaxException` raised for a tag or expression that is never
    closed is now reported against the line the construct begins on, rather
    than the point at which the search for the closing token gave up, which
    for an unclosed construct is the end of the template.  The message of the
    exception is amended to indicate that the position given is where the
    unterminated construct begins. ([#428](https://github.com/sqlalchemy/mako/issues/428))

    References: #245, #428, #430

Assets 2
Loading