mirror of
https://github.com/django/django.git
synced 2025-08-04 10:59:45 +00:00
Replaced smart_* by force_* calls whenever possible
The smart_* version should only be used when a lazy string should keep its lazy status.
This commit is contained in:
parent
b1d6b0a7b1
commit
2ced2f785d
23 changed files with 60 additions and 63 deletions
|
@ -369,7 +369,7 @@ to you, the developer, to handle the fact that you will receive bytestrings if
|
|||
you configure your table(s) to use ``utf8_bin`` collation. Django itself should
|
||||
mostly work smoothly with such columns (except for the ``contrib.sessions``
|
||||
``Session`` and ``contrib.admin`` ``LogEntry`` tables described below), but
|
||||
your code must be prepared to call ``django.utils.encoding.smart_text()`` at
|
||||
your code must be prepared to call ``django.utils.encoding.force_text()`` at
|
||||
times if it really wants to work with consistent data -- Django will not do
|
||||
this for you (the database backend layer and the model population layer are
|
||||
separated internally so the database layer doesn't know it needs to make this
|
||||
|
|
|
@ -163,7 +163,7 @@ for converting back and forth between Unicode and bytestrings.
|
|||
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_text()``. Call it as early as
|
||||
Normally, you'll only need to use ``force_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.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue