Suppose I've got a custom form label with some HTML on it like so:
SafeUnicode('<span class="superscript">™</span>')
Why would Django 1.2 have a function mark_safe if this exist? What are the differences if any?
Thanks for the help!
Suppose I've got a custom form label with some HTML on it like so:
SafeUnicode('<span class="superscript">™</span>')
Why would Django 1.2 have a function mark_safe if this exist? What are the differences if any?
Thanks for the help!
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).