[py3] Ported django.utils.encoding.

* Renamed smart_unicode to smart_text (but kept the old name under
  Python 2 for backwards compatibility).
* Renamed smart_str to smart_bytes.
* Re-introduced smart_str as an alias for smart_text under Python 3
  and smart_bytes under Python 2 (which is backwards compatible).
  Thus smart_str always returns a str objects.
* Used the new smart_str in a few places where both Python 2 and 3
  want a str.

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