Filter output gets cached/compiled if a filter has no arguments or the
arguments are strings. I believe this is undocumented behaviour, but
makes a lot of sense.

However, this is problematic if the output is supposed to vary according
to some aspect of the request; the matchdict in my case.

The recommended way to access the request in the pyramid_jinja2 examples
is to use a threadlocal get_current_request. This can create conditions
where the filter output is cached for the first route that was called
and remains for subsequent requests as described above until the
application is reloaded.

This example gets cached::

    {{ 'some_route'|some_filter('foo') }}

Whereas passing the request (or any other var) prevents the
caching-behaviour::

    {{ 'some_route'|some_filter(request, 'foo') }}

Is there some way to configure certain filters to not be cached?

Or would it be better to pass the request object to each filter that
needed it as shown above, and avoid the use of threadlocals?

On the face of it, the later seems a more pyramid-like thing to do and,
whilst adding some bulk to templates, arguably makes the code more
readable.

I couldn't see any documentation for this caching-behaviour either in
Jinja2 or pyramid_jinja2, so it's difficult to interpret intended use.