On 11/17/07, Ivan Sagalaev <Man...@softwaremaniacs.org> wrote:

I'm also just getting started on learning this, but feel like I've got a
reasonably good understanding from the docs and a bit of looking at the
code, so I'll take a stab at answering.

First, I don't get why .is_safe attribute is needed at all. If my filter

From reading the doc, I got the impression that is_safe is for filters that
don't mark_safe their output, but that also do not do anything to introduce
anything "unsafe" in their output.  Therefore, if they are given a safe
string on input, their output will be automatically marked safe.  Setting
is_safe to True for a filter that always mark_safe's its output appears to
be a no-op -- the framework will call mark_safe a 2nd time on something that
has already been marked safe, which is harmless.  However, there are a few
filters in defaultfilters.py that do in fact always return mark_safe'd
output but also have is_safe set to True.  I don't understand what that
accomplishes so perhaps I am missing something here.

Then, looking at default filters I see that .is_safe is set to False for

But they are not returning strings, they are returning ints (or lists, or
whatever).  If is_safe was set to True for these filters, then their output
would automatically be marked safe whenever they were called with safe
input, meaning whatever they were returning would be turned into a (safe)
string, changing the type of their output.  is_safe=True is for filters that
return strings, not numbers or whatever else.

And 'needs_autoescape' escapes me absolutely... If I'm dealing with user

You said "dealing with user content", so you have in your mind that input
your filter is given must be escaped.  What if you were writing a filter
that could operate on either user-generated (untrusted) input that does need
to be escaped or trusted input that may contain HTML and should not be
escaped?  That's what needs_autoescape is for.  It's for filters that are
going to mark_safe their output but need to know whether or not their input
should be escaped as they process it.  They're producing something that will
be exempt from further escaping, so they need to know the current autoescape
setting in order to determine whether their input should be escaped as it is
incorporated into their output, because this is that last chance for getting
it escaped.

As I mentioned above, I don't believe it is necessary to set is_safe to True
for a filter that mark_safe's it output, but I might be missing something
there.

As for whether you need to ask for autoescape -- is there any use case for
your filter where its input could contain HTML that should not be escaped?
If so, then you should ask for autoescape and only escape the input you are
given if autoescape is on.

Anyway, that's my take on it.  Malcolm can correct where I've gotten things
wrong.

Cheers,
Karen