From f8d5a22db3230634d2b42c59909985f31875a9f5 Mon Sep 17 00:00:00 2001
From: Martin von Gagern <gagern@google.com>
Date: Thu, 4 Jul 2019 11:48:45 +0100
Subject: [PATCH] Support n filter in the page tag

In some situations, it is inconvenient to pass default_filters in the
Template constructor depending on the template in question.  It might be
easier in such situations to express page filters in the template itself.
However, dropping the existing default_filters (either explicitly set or the
default of ["str"] resp. ["unicode"]) might break existing templates.

The code change here comes to the rescue in such situations.  Existing
templates keep working as they are, but editors of templates get a tool to
replace the default filters for specific templates.  They do take on the
responsibility of turning all encountered inputs into strings, lest they
fail along the lines of https://github.com/sqlalchemy/mako/issues/272.

This change should be sufficiently backwards compatible to not cause any
concerns.  Sure, technically a "n" filter at page tag level was treated as a
no-op so far.  So theoretically existing templates could break.  But there
was no incentive to have such an "n" filter at the page tag level, and the
expressed semantics of the "n" filter is to suppress default filters, so
semantically anyone relying on it being a no-op in that situation was using
unsupported hacks anyway.
---
 doc/build/filtering.rst | 14 ++++++++++++++
 mako/codegen.py         |  2 +-
 test/test_filters.py    | 11 +++++++++++
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/doc/build/filtering.rst b/doc/build/filtering.rst
index 3bcb25a6..531b1552 100644
--- a/doc/build/filtering.rst
+++ b/doc/build/filtering.rst
@@ -169,6 +169,20 @@ will render ``myexpression`` with no filtering of any kind, and:
 
 will render ``myexpression`` using the ``trim`` filter only.
 
+Including the ``n`` filter in a ``<%page>`` tag will only disable
+``default_filters``. In effect this makes the filters from the tag replace
+default filters instead of adding to them. For example:
+
+.. sourcecode:: mako
+
+    <%page expression_filter="n, json.dumps"/>
+    data = {a: ${123}, b: ${"123"}};
+
+will suppress turning the values into strings using the default filter, so that
+``json.dumps`` (which requires ``imports=["import json"]`` or something
+equivalent) can take the value type into account, formatting numbers as numeric
+literals and strings as string literals.
+
 Filtering Defs and Blocks
 =========================
 
diff --git a/mako/codegen.py b/mako/codegen.py
index 1acc5e6a..5ca7b041 100644
--- a/mako/codegen.py
+++ b/mako/codegen.py
@@ -802,7 +802,7 @@ def locate_encode(name):
             if is_expression:
                 if self.compiler.pagetag:
                     args = self.compiler.pagetag.filter_args.args + args
-                if self.compiler.default_filters:
+                if self.compiler.default_filters and "n" not in args:
                     args = self.compiler.default_filters + args
         for e in args:
             # if filter given as a function, get just the identifier portion
diff --git a/test/test_filters.py b/test/test_filters.py
index 598cb456..a58a01f9 100644
--- a/test/test_filters.py
+++ b/test/test_filters.py
@@ -294,6 +294,17 @@ def test_nflag(self):
         )
         assert t.render().strip() == "&lt;tag&gt;this is html&lt;/tag&gt;"
 
+    def test_global_json(self):
+        t = Template(
+            """
+<%!
+import json
+%><%page expression_filter="n, json.dumps"/>
+data = {a: ${123}, b: ${"123"}};
+        """
+        )
+        assert t.render().strip() == """data = {a: 123, b: "123"};"""
+
     def test_non_expression(self):
         t = Template(
             """