diff options
Diffstat (limited to 'docs/ref/unicode.txt')
| -rw-r--r-- | docs/ref/unicode.txt | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt index b9253e70b3..ffab647379 100644 --- a/docs/ref/unicode.txt +++ b/docs/ref/unicode.txt @@ -129,7 +129,7 @@ Conversion functions The ``django.utils.encoding`` module contains a few functions that are handy for converting back and forth between Unicode and bytestrings. -* ``smart_unicode(s, encoding='utf-8', strings_only=False, errors='strict')`` +* ``smart_text(s, encoding='utf-8', strings_only=False, errors='strict')`` converts its input to a Unicode string. The ``encoding`` parameter specifies the input encoding. (For example, Django uses this internally when processing form input data, which might not be UTF-8 encoded.) The @@ -139,27 +139,27 @@ for converting back and forth between Unicode and bytestrings. that are accepted by Python's ``unicode()`` function for its error handling. - If you pass ``smart_unicode()`` an object that has a ``__unicode__`` + If you pass ``smart_text()`` an object that has a ``__unicode__`` method, it will use that method to do the conversion. -* ``force_unicode(s, encoding='utf-8', strings_only=False, - errors='strict')`` is identical to ``smart_unicode()`` in almost all +* ``force_text(s, encoding='utf-8', strings_only=False, + errors='strict')`` is identical to ``smart_text()`` in almost all cases. The difference is when the first argument is a :ref:`lazy - translation <lazy-translations>` instance. While ``smart_unicode()`` - preserves lazy translations, ``force_unicode()`` forces those objects to a + translation <lazy-translations>` instance. While ``smart_text()`` + preserves lazy translations, ``force_text()`` forces those objects to a Unicode string (causing the translation to occur). Normally, you'll want - to use ``smart_unicode()``. However, ``force_unicode()`` is useful in + to use ``smart_text()``. However, ``force_text()`` is useful in template tags and filters that absolutely *must* have a string to work with, not just something that can be converted to a string. -* ``smart_str(s, encoding='utf-8', strings_only=False, errors='strict')`` - is essentially the opposite of ``smart_unicode()``. It forces the first +* ``smart_bytes(s, encoding='utf-8', strings_only=False, errors='strict')`` + is essentially the opposite of ``smart_text()``. It forces the first argument to a bytestring. The ``strings_only`` parameter has the same - behavior as for ``smart_unicode()`` and ``force_unicode()``. This is + behavior as for ``smart_text()`` and ``force_text()``. This is slightly different semantics from Python's builtin ``str()`` function, but the difference is needed in a few places within Django's internals. -Normally, you'll only need to use ``smart_unicode()``. Call it as early as +Normally, you'll only need to use ``smart_text()``. Call it as early as possible on any input data that might be either Unicode or a bytestring, and from then on, you can treat the result as always being Unicode. @@ -324,7 +324,7 @@ A couple of tips to remember when writing your own template tags and filters: * Always return Unicode strings from a template tag's ``render()`` method and from template filters. -* Use ``force_unicode()`` in preference to ``smart_unicode()`` in these +* Use ``force_text()`` in preference to ``smart_text()`` in these places. Tag rendering and filter calls occur as the template is being rendered, so there is no advantage to postponing the conversion of lazy translation objects into strings. It's easier to work solely with Unicode |