Question

Suppose I’ve got a custom form label with some HTML on it like so:

SafeUnicode('<span class="superscript">&trade;</span>')

Why would Django 1.2 have a function mark_safe if this exist? What are the differences if any?

Thanks for the help!

Answer 1

mark_safe is a factory function which encapsulate a bit of type-checking logic in order to return, as appropriate, either a SafeUnicode or a SafeString (or possibly some other subclass of SafeData should you have defined any such subclasses). The source is easily short enough to quote…:

89  def mark_safe(s):
90      """
91      Explicitly mark a string as safe for (HTML) output purposes. The returned
92      object can be used everywhere a string or unicode object is appropriate.
93  
94      Can be called multiple times on a single string.
95      """
96      if isinstance(s, SafeData):
97          return s
98      if isinstance(s, str) or (isinstance(s, Promise) and s._delegate_str):
99          return SafeString(s)
100     if isinstance(s, (unicode, Promise)):
101         return SafeUnicode(s)
102     return SafeString(str(s))

Just using SafeUnicode(s) instead of make_safe(s) will be minutely faster, but could get you in trouble if you’re potentially dealing with a type and value that don’t happily support being passed to the SafeUnicode initializer (e.g., a byte string with non-ascii codes, a non-string, a Promise with a string delegate, …). If you are 100% certain that you know what you’re doing, nothing stops you from going for the nanoseconds-saving approach;-).

By the way, some questions about open-source code (no matter how well documented, and Django’s docs are really impressive) are often best answered by first having a look at the code (and then asking if the code’s too complex or subtle to follow with assurance).