mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-04 10:59:45 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

[py3] Ported django.utils.encoding.

Browse source 
* 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.
This commit is contained in:
Aymeric Augustin 2012-07-21 10:00:10 +02:00
parent ee191715ea
commit c5ef65bcf3
125 changed files with 629 additions and 583 deletions
Download patch file Download diff file Expand all files Collapse all files

24
docs/ref/unicode.txt
View file

@ -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