mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00
Code Issues 32 Releases Wiki Activity

Refs #23919, #27778 -- Removed obsolete mentions of unicode.

Browse Source
This commit is contained in:
Vytis Banaitis
2017-01-20 23:04:05 +02:00
committed by Tim Graham
parent 888c1e9bfe
commit d1bab24e01
63 changed files with 201 additions and 251 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/howto/custom-management-commands.txt
View File

@@ -305,7 +305,7 @@ the :meth:`~BaseCommand.handle` method must be implemented.
The actual logic of the command. Subclasses must implement this method.
It may return a Unicode string which will be printed to ``stdout`` (wrapped
It may return a string which will be printed to ``stdout`` (wrapped
by ``BEGIN;`` and ``COMMIT;`` if :attr:`output_transaction` is ``True``).
.. method:: BaseCommand.check(app_configs=None, tags=None, display_num_errors=False)

12
docs/howto/custom-template-tags.txt
View File

@@ -188,12 +188,11 @@ Filters and auto-escaping
-------------------------
When writing a custom filter, give some thought to how the filter will interact
with Django's auto-escaping behavior. Note that three types of strings can be
with Django's auto-escaping behavior. Note that two types of strings can be
passed around inside the template code:
* **Raw strings** are the native Python ``str`` or ``unicode`` types. On
output, they're escaped if auto-escaping is in effect and presented
unchanged, otherwise.
* **Raw strings** are the native Python strings. On output, they're escaped if
auto-escaping is in effect and presented unchanged, otherwise.
* **Safe strings** are strings that have been marked safe from further
escaping at output time. Any necessary escaping has already been done.
@@ -229,9 +228,8 @@ Template filter code falls into one of two situations:
The reason ``is_safe`` is necessary is because there are plenty of
normal string operations that will turn a ``SafeData`` object back into
a normal ``str`` or ``unicode`` object and, rather than try to catch
them all, which would be very difficult, Django repairs the damage after
the filter has completed.
a normal ``str`` object and, rather than try to catch them all, which would
be very difficult, Django repairs the damage after the filter has completed.
For example, suppose you have a filter that adds the string ``xx`` to
the end of any input. Since this introduces no dangerous HTML characters

12
docs/ref/contrib/gis/geos.txt
View File

@@ -197,14 +197,14 @@ given ``geo_input`` argument, and then assumes the proper geometry subclass
The following input formats, along with their corresponding Python types,
are accepted:
======================= ======================
======================= ==========
Format Input Type
======================= ======================
WKT / EWKT ``str`` or ``unicode``
HEX / HEXEWKB ``str`` or ``unicode``
======================= ==========
WKT / EWKT ``str``
HEX / HEXEWKB ``str``
WKB / EWKB ``buffer``
GeoJSON ``str`` or ``unicode``
======================= ======================
GeoJSON ``str``
======================= ==========
.. classmethod:: GEOSGeometry.from_gml(gml_string)

12
docs/ref/contrib/syndication.txt
View File

@@ -114,7 +114,7 @@ into those elements.
calling the methods ``item_title()`` and ``item_description()`` on
the :class:`~django.contrib.syndication.views.Feed` class. They are passed
a single parameter, ``item``, which is the object itself. These are
optional; by default, the unicode representation of the object is used for
optional; by default, the string representation of the object is used for
both.
If you want to do any special formatting for either the title or
@@ -615,7 +615,7 @@ This example illustrates all possible attributes and methods for a
# ITEM TITLE AND DESCRIPTION -- If title_template or
# description_template are not defined, these are used instead. Both are
# optional, by default they will use the unicode representation of the
# optional, by default they will use the string representation of the
# item.
def item_title(self, item):
@@ -940,8 +940,8 @@ They share this interface:
Any extra keyword arguments you pass to ``__init__`` will be stored in
``self.feed`` for use with `custom feed generators`_.
All parameters should be Unicode objects, except ``categories``, which
should be a sequence of Unicode objects. Beware that some control characters
All parameters should be strings, except ``categories``, which should be a
sequence of strings. Beware that some control characters
are `not allowed <http://www.w3.org/International/questions/qa-controls>`_
in XML documents. If your content has some of them, you might encounter a
:exc:`ValueError` when producing the feed.
@@ -971,13 +971,13 @@ They share this interface:
Extra keyword arguments will be stored for `custom feed generators`_.
All parameters, if given, should be Unicode objects, except:
All parameters, if given, should be strings, except:
* ``pubdate`` should be a Python :class:`~datetime.datetime` object.
* ``updateddate`` should be a Python :class:`~datetime.datetime` object.
* ``enclosures`` should be a list of
:class:`django.utils.feedgenerator.Enclosure` instances.
* ``categories`` should be a sequence of Unicode objects.
* ``categories`` should be a sequence of strings.
:meth:`.SyndicationFeed.write`
Outputs the feed in the given encoding to outfile, which is a file-like object.

2
docs/ref/files/uploads.txt
View File

@@ -196,7 +196,7 @@ attributes:
``field_name`` is a string name of the file ``<input>`` field.
``file_name`` is the unicode filename that was provided by the browser.
``file_name`` is the filename provided by the browser.
``content_type`` is the MIME type provided by the browser -- E.g.
``'image/jpeg'``.

8
docs/ref/forms/api.txt
View File

@@ -112,7 +112,7 @@ messages::
{'sender': ['Enter a valid email address.'], 'subject': ['This field is required.']}
In this dictionary, the keys are the field names, and the values are lists of
Unicode strings representing the error messages. The error messages are stored
strings representing the error messages. The error messages are stored
in lists because a field can have multiple error messages.
You can access :attr:`~Form.errors` without having to call
@@ -357,8 +357,8 @@ it, you can access the clean data via its ``cleaned_data`` attribute::
{'cc_myself': True, 'message': 'Hi there', 'sender': 'foo@example.com', 'subject': 'hello'}
Note that any text-based field -- such as ``CharField`` or ``EmailField`` --
always cleans the input into a Unicode string. We'll cover the encoding
implications later in this document.
always cleans the input into a string. We'll cover the encoding implications
later in this document.
If your data does *not* validate, the ``cleaned_data`` dictionary contains
only the valid fields::
@@ -490,7 +490,7 @@ Notice the following:
Although ``<table>`` output is the default output style when you ``print`` a
form, other output styles are available. Each style is available as a method on
a form object, and each rendering method returns a Unicode object.
a form object, and each rendering method returns a string.
``as_p()``
----------

26
docs/ref/forms/fields.txt
View File

@@ -88,9 +88,8 @@ To specify that a field is *not* required, pass ``required=False`` to the
If a ``Field`` has ``required=False`` and you pass ``clean()`` an empty value,
then ``clean()`` will return a *normalized* empty value rather than raising
``ValidationError``. For ``CharField``, this will be a Unicode empty string.
For other ``Field`` classes, it might be ``None``. (This varies from field to
field.)
``ValidationError``. For ``CharField``, this will be an empty string. For other
``Field`` classes, it might be ``None``. (This varies from field to field.)
Widgets of required form fields have the ``required`` HTML attribute. Set the
:attr:`Form.use_required_attribute` attribute to ``False`` to disable it. The
@@ -371,7 +370,7 @@ For each field, we describe the default widget used if you don't specify
* Default widget: :class:`TextInput`
* Empty value: Whatever you've given as :attr:`empty_value`.
* Normalizes to: A Unicode object.
* Normalizes to: A string.
* Validates ``max_length`` or ``min_length``, if they are provided.
Otherwise, all inputs are valid.
* Error message keys: ``required``, ``max_length``, ``min_length``
@@ -402,7 +401,7 @@ For each field, we describe the default widget used if you don't specify
* Default widget: :class:`Select`
* Empty value: ``''`` (an empty string)
* Normalizes to: A Unicode object.
* Normalizes to: A string.
* Validates that the given value exists in the list of choices.
* Error message keys: ``required``, ``invalid_choice``
@@ -585,7 +584,7 @@ For each field, we describe the default widget used if you don't specify
* Default widget: :class:`EmailInput`
* Empty value: ``''`` (an empty string)
* Normalizes to: A Unicode object.
* Normalizes to: A string.
* Validates that the given value is a valid email address, using a
moderately complex regular expression.
* Error message keys: ``required``, ``invalid``
@@ -629,7 +628,7 @@ For each field, we describe the default widget used if you don't specify
* Default widget: :class:`Select`
* Empty value: ``None``
* Normalizes to: A unicode object
* Normalizes to: A string.
* Validates that the selected choice exists in the list of choices.
* Error message keys: ``required``, ``invalid_choice``
@@ -747,8 +746,7 @@ For each field, we describe the default widget used if you don't specify
* Default widget: :class:`TextInput`
* Empty value: ``''`` (an empty string)
* Normalizes to: A Unicode object. IPv6 addresses are
normalized as described below.
* Normalizes to: A string. IPv6 addresses are normalized as described below.
* Validates that the given value is a valid IP address.
* Error message keys: ``required``, ``invalid``
@@ -780,7 +778,7 @@ For each field, we describe the default widget used if you don't specify
* Default widget: :class:`SelectMultiple`
* Empty value: ``[]`` (an empty list)
* Normalizes to: A list of Unicode objects.
* Normalizes to: A list of strings.
* Validates that every value in the given list of values exists in the list
of choices.
* Error message keys: ``required``, ``invalid_choice``, ``invalid_list``
@@ -829,7 +827,7 @@ For each field, we describe the default widget used if you don't specify
* Default widget: :class:`TextInput`
* Empty value: ``''`` (an empty string)
* Normalizes to: A Unicode object.
* Normalizes to: A string.
* Validates that the given value matches against a certain regular
expression.
* Error message keys: ``required``, ``invalid``
@@ -856,7 +854,7 @@ For each field, we describe the default widget used if you don't specify
* Default widget: :class:`TextInput`
* Empty value: ``''`` (an empty string)
* Normalizes to: A Unicode object.
* Normalizes to: A string.
* Validates that the given value contains only letters, numbers,
underscores, and hyphens.
* Error messages: ``required``, ``invalid``
@@ -902,7 +900,7 @@ For each field, we describe the default widget used if you don't specify
* Default widget: :class:`URLInput`
* Empty value: ``''`` (an empty string)
* Normalizes to: A Unicode object.
* Normalizes to: A string.
* Validates that the given value is a valid URL.
* Error message keys: ``required``, ``invalid``
@@ -936,7 +934,7 @@ Slightly complex built-in ``Field`` classes
* Default widget: :class:`TextInput`
* Empty value: ``''`` (an empty string)
* Normalizes to: A Unicode object.
* Normalizes to: A string.
* Validates the given value against each of the fields specified
as an argument to the ``ComboField``.
* Error message keys: ``required``, ``invalid``

22
docs/ref/models/querysets.txt
View File

@@ -2391,10 +2391,9 @@ Note the first query will match ``'Beatles Blog'``, ``'beatles blog'``,
.. admonition:: SQLite users
When using the SQLite backend and Unicode (non-ASCII) strings, bear in
mind the :ref:`database note <sqlite-string-matching>` about string
comparisons. SQLite does not do case-insensitive matching for Unicode
strings.
When using the SQLite backend and non-ASCII strings, bear in mind the
:ref:`database note <sqlite-string-matching>` about string comparisons.
SQLite does not do case-insensitive matching for non-ASCII strings.
.. fieldlookup:: contains
@@ -2438,9 +2437,8 @@ SQL equivalent::
.. admonition:: SQLite users
When using the SQLite backend and Unicode (non-ASCII) strings, bear in
mind the :ref:`database note <sqlite-string-matching>` about string
comparisons.
When using the SQLite backend and non-ASCII strings, bear in mind the
:ref:`database note <sqlite-string-matching>` about string comparisons.
.. fieldlookup:: in
@@ -2572,9 +2570,8 @@ SQL equivalent::
.. admonition:: SQLite users
When using the SQLite backend and Unicode (non-ASCII) strings, bear in
mind the :ref:`database note <sqlite-string-matching>` about string
comparisons.
When using the SQLite backend and non-ASCII strings, bear in mind the
:ref:`database note <sqlite-string-matching>` about string comparisons.
.. fieldlookup:: endswith
@@ -2614,9 +2611,8 @@ SQL equivalent::
.. admonition:: SQLite users
When using the SQLite backend and Unicode (non-ASCII) strings, bear in
mind the :ref:`database note <sqlite-string-matching>` about string
comparisons.
When using the SQLite backend and non-ASCII strings, bear in mind the
:ref:`database note <sqlite-string-matching>` about string comparisons.
.. fieldlookup:: range

5
docs/ref/request-response.txt
View File

@@ -416,7 +416,7 @@ a subclass of dictionary. Exceptions are outlined here:
``mutable=True`` to its ``__init__()``.
Strings for setting both keys and values will be converted from ``encoding``
to unicode. If encoding is not set, it defaults to :setting:`DEFAULT_CHARSET`.
to ``str``. If encoding is not set, it defaults to :setting:`DEFAULT_CHARSET`.
.. classmethod:: QueryDict.fromkeys(iterable, value='', mutable=False, encoding=None)
@@ -654,8 +654,7 @@ Attributes
.. attribute:: HttpResponse.content
A bytestring representing the content, encoded from a Unicode
object if necessary.
A bytestring representing the content, encoded from a string if necessary.
.. attribute:: HttpResponse.charset

3
docs/ref/templates/builtins.txt
View File

@@ -1934,8 +1934,7 @@ If ``value`` is ``Totally LOVING this Album!``, the output will be
-------------
Returns the value turned into a list. For a string, it's a list of characters.
For an integer, the argument is cast into an unicode string before creating a
list.
For an integer, the argument is cast to a string before creating a list.
For example::

48
docs/ref/unicode.txt
View File

@@ -3,8 +3,8 @@ Unicode data
============
Django natively supports Unicode data everywhere. Providing your database can
somehow store the data, you can safely pass around Unicode strings to
templates, models and the database.
somehow store the data, you can safely pass around strings to templates,
models, and the database.
This document tells you what you need to know if you're writing applications
that use data or templates that are encoded in something other than ASCII.
@@ -35,11 +35,10 @@ able to store certain characters in the database, and information will be lost.
.. _section 2: https://docs.oracle.com/database/121/NLSPG/ch2charset.htm#NLSPG002
.. _section 11: https://docs.oracle.com/database/121/NLSPG/ch11charsetmig.htm#NLSPG011
All of Django's database backends automatically convert Unicode strings into
All of Django's database backends automatically convert strings into
the appropriate encoding for talking to the database. They also automatically
convert strings retrieved from the database into Python Unicode strings. You
don't even need to tell Django what encoding your database uses: that is
handled transparently.
convert strings retrieved from the database into strings. You don't even need
to tell Django what encoding your database uses: that is handled transparently.
For more, see the section "The database API" below.
@@ -48,7 +47,7 @@ General string handling
Whenever you use strings with Django -- e.g., in database lookups, template
rendering or anywhere else -- you have two choices for encoding those strings.
You can use normal Unicode strings or bytestrings (starting with a 'b').
You can use normal strings or bytestrings (starting with a 'b').
.. warning::
@@ -74,13 +73,13 @@ using your application -- and if that person chooses a different setting, your
code must still continue to work. Ergo, it cannot rely on that setting.
In most cases when Django is dealing with strings, it will convert them to
Unicode strings before doing anything else. So, as a general rule, if you pass
in a bytestring, be prepared to receive a Unicode string back in the result.
strings before doing anything else. So, as a general rule, if you pass
in a bytestring, be prepared to receive a string back in the result.
Translated strings
------------------
Aside from Unicode strings and bytestrings, there's a third type of string-like
Aside from strings and bytestrings, there's a third type of string-like
object you may encounter when using Django. The framework's
internationalization features introduce the concept of a "lazy translation" --
a string that has been marked as translated but whose actual translation result
@@ -93,7 +92,7 @@ Normally, you won't have to worry about lazy translations. Just be aware that
if you examine an object and it claims to be a
``django.utils.functional.__proxy__`` object, it is a lazy translation.
Calling ``str()`` with the lazy translation as the argument will generate a
Unicode string in the current locale.
string in the current locale.
For more details about lazy translation objects, refer to the
:doc:`internationalization </topics/i18n/index>` documentation.
@@ -102,17 +101,17 @@ Useful utility functions
------------------------
Because some string operations come up again and again, Django ships with a few
useful functions that should make working with Unicode and bytestring objects
useful functions that should make working with string and bytestring objects
a bit easier.
Conversion functions
~~~~~~~~~~~~~~~~~~~~
The ``django.utils.encoding`` module contains a few functions that are handy
for converting back and forth between Unicode and bytestrings.
for converting back and forth between strings and bytestrings.
* ``smart_text(s, encoding='utf-8', strings_only=False, errors='strict')``
converts its input to a Unicode string. The ``encoding`` parameter
converts its input to a 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
``strings_only`` parameter, if set to True, will result in Python
@@ -126,7 +125,7 @@ for converting back and forth between Unicode and bytestrings.
cases. The difference is when the first argument is a :ref:`lazy
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
string (causing the translation to occur). Normally, you'll want
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.
@@ -139,8 +138,8 @@ for converting back and forth between Unicode and bytestrings.
but the difference is needed in a few places within Django's internals.
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.
possible on any input data that might be either a string or a bytestring, and
from then on, you can treat the result as always being a string.
.. _uri-and-iri-handling:
@@ -225,13 +224,13 @@ double-quoting problems.
Models
======
Because all strings are returned from the database as Unicode strings, model
Because all strings are returned from the database as ``str`` objects, model
fields that are character based (CharField, TextField, URLField, etc.) will
contain Unicode values when Django retrieves data from the database. This
is *always* the case, even if the data could fit into an ASCII bytestring.
You can pass in bytestrings when creating a model or populating a field, and
Django will convert it to Unicode when it needs to.
Django will convert it to strings when it needs to.
Taking care in ``get_absolute_url()``
-------------------------------------
@@ -263,7 +262,7 @@ non-ASCII characters would have been removed in quoting in the first line.)
The database API
================
You can pass either Unicode strings or UTF-8 bytestrings as arguments to
You can pass either strings or UTF-8 bytestrings as arguments to
``filter()`` methods and the like in the database API. The following two
querysets are identical::
@@ -273,11 +272,12 @@ querysets are identical::
Templates
=========
You can use either Unicode or bytestrings when creating templates manually::
You can use either strings or UTF-8 bytestrings when creating templates
manually::
from django.template import Template
t1 = Template(b'This is a bytestring template.')
t2 = Template('This is a Unicode template.')
t2 = Template('This is a string template.')
But the common case is to read templates from the filesystem, and this creates
a slight complication: not all filesystems store their data encoded as UTF-8.
@@ -294,13 +294,13 @@ Template tags and filters
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
* Always return strings from a template tag's ``render()`` method
and from template filters.
* 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
translation objects into strings. It's easier to work solely with
strings at that point.
.. _unicode-files:

27
docs/ref/utils.txt
View File

@@ -276,13 +276,13 @@ The functions defined in this module share the following properties:
This is an algorithm from section 3.2 of :rfc:`3987#section-3.2`.
Takes a URI in ASCII bytes and returns a unicode string containing the
encoded result.
Takes a URI in ASCII bytes and returns a string containing the encoded
result.
.. function:: filepath_to_uri(path)
Convert a file system path to a URI portion that is suitable for inclusion
in a URL. The path is assumed to be either UTF-8 or unicode.
in a URL. The path is assumed to be either UTF-8 bytes or string.
This method will encode certain characters that would normally be
recognized as special characters for URIs. Note that this method does not
@@ -346,13 +346,13 @@ https://web.archive.org/web/20110718035220/http://diveintomark.org/archives/2004
Any extra keyword arguments you pass to ``__init__`` will be stored in
``self.feed``.
All parameters should be Unicode objects, except ``categories``, which
should be a sequence of Unicode objects.
All parameters should be strings, except ``categories``, which should
be a sequence of strings.
.. method:: add_item(title, link, description, author_email=None, author_name=None, author_link=None, pubdate=None, comments=None, unique_id=None, categories=(), item_copyright=None, ttl=None, updateddate=None, enclosures=None, **kwargs)
Adds an item to the feed. All args are expected to be Python ``unicode``
objects except ``pubdate`` and ``updateddate``, which are ``datetime.datetime``
Adds an item to the feed. All args are expected to be strings except
``pubdate`` and ``updateddate``, which are ``datetime.datetime``
objects, and ``enclosures``, which is a list of ``Enclosure`` instances.
.. method:: num_items()
@@ -802,7 +802,7 @@ appropriate entities.
.. function:: mark_safe(s)
Explicitly mark a string as safe for (HTML) output purposes. The returned
object can be used everywhere a string or unicode object is appropriate.
object can be used everywhere a string is appropriate.
Can be called multiple times on a single string.
@@ -1030,16 +1030,15 @@ For a complete discussion on the usage of the following see the
.. function:: gettext(message)
Translates ``message`` and returns it in a UTF-8 bytestring
Translates ``message`` and returns it in a UTF-8 bytestring.
.. function:: ugettext(message)
Translates ``message`` and returns it in a unicode string
Translates ``message`` and returns it as a string.
.. function:: pgettext(context, message)
Translates ``message`` given the ``context`` and returns
it in a unicode string.
Translates ``message`` given the ``context`` and returns it as a string.
For more information, see :ref:`contextual-markers`.
@@ -1067,12 +1066,12 @@ For a complete discussion on the usage of the following see the
.. function:: ungettext(singular, plural, number)
Translates ``singular`` and ``plural`` and returns the appropriate string
based on ``number`` in a unicode string.
based on ``number`` as a string.
.. function:: npgettext(context, singular, plural, number)
Translates ``singular`` and ``plural`` and returns the appropriate string
based on ``number`` and the ``context`` in a unicode string.
based on ``number`` and the ``context`` as a string.
.. function:: ngettext_lazy(singular, plural, number)
.. function:: ungettext_lazy(singular, plural, number)

2
docs/ref/views.txt
View File

@@ -121,7 +121,7 @@ default, call the view ``django.views.defaults.permission_denied``.
This view loads and renders the template ``403.html`` in your root template
directory, or if this file does not exist, instead serves the text
"403 Forbidden", as per :rfc:`7231#section-6.5.3` (the HTTP 1.1 Specification).
The template context contains ``exception``, which is the unicode
The template context contains ``exception``, which is the string
representation of the exception that triggered the view.
``django.views.defaults.permission_denied`` is triggered by a

2
docs/topics/db/models.txt
View File

@@ -762,7 +762,7 @@ You can override most of these -- see `overriding predefined model methods`_,
below -- but there are a couple that you'll almost always want to define:
:meth:`~Model.__str__`
A Python "magic method" that returns a unicode "representation" of any
A Python "magic method" that returns a string representation of any
object. This is what Python and Django will use whenever a model
instance needs to be coerced and displayed as a plain string. Most
notably, this happens when you display an object in an interactive

5
docs/topics/i18n/timezones.txt
View File

@@ -472,11 +472,6 @@ Setup
of local time. This shields you from subtle and unreproducible bugs around
Daylight Saving Time (DST) transitions.
In this regard, time zones are comparable to ``unicode`` in Python. At first
it's hard. You get encoding and decoding errors. Then you learn the rules.
And some problems disappear -- you never get mangled output again when your
application receives non-ASCII input.
When you enable time zone support, you'll encounter some errors because
you're using naive datetimes where Django expects aware datetimes. Such
errors show up when running tests and they're easy to fix. You'll quickly

21
docs/topics/i18n/translation.txt
View File

@@ -57,12 +57,9 @@ as a shorter alias, ``_``, to save typing.
global namespace, as an alias for ``gettext()``. In Django, we have chosen
not to follow this practice, for a couple of reasons:
1. For international character set (Unicode) support,
:func:`~django.utils.translation.ugettext` is more useful than
``gettext()``. Sometimes, you should be using
:func:`~django.utils.translation.ugettext_lazy` as the default
translation method for a particular file. Without ``_()`` in the
global namespace, the developer has to think about which is the
1. Sometimes, you should use :func:`~django.utils.translation.ugettext_lazy`
as the default translation method for a particular file. Without ``_()``
in the global namespace, the developer has to think about which is the
most appropriate translation function.
2. The underscore character (``_``) is used to represent "the previous
@@ -418,7 +415,7 @@ Working with lazy translation objects
-------------------------------------
The result of a ``ugettext_lazy()`` call can be used wherever you would use a
unicode string (a :class:`str` object) in other Django code, but it may not
string (a :class:`str` object) in other Django code, but it may not
work with arbitrary Python code. For example, the following won't work because
the `requests <https://pypi.python.org/pypi/requests/>`_ library doesn't handle
``ugettext_lazy`` objects::
@@ -434,14 +431,14 @@ strings before passing them to non-Django code::
If you try to use a ``ugettext_lazy()`` result where a bytestring (a
:class:`bytes` object) is expected, things won't work as expected since a
``ugettext_lazy()`` object doesn't know how to convert itself to a bytestring.
You can't use a unicode string inside a bytestring, either, so this is
consistent with normal Python behavior. For example, putting a unicode proxy
into a unicode string is fine::
You can't use a string inside a bytestring, either, so this is consistent with
normal Python behavior. For example, putting a string proxy into a string is
fine::
"Hello %s" % ugettext_lazy("people")
But you can't insert a unicode object into a bytestring and nor can you insert
a unicode proxy there::
But you can't insert a string into a bytestring and nor can you insert
a string proxy there::
b"Hello %s" % ugettext_lazy("people")

2
docs/topics/migrations.txt
View File

@@ -653,7 +653,7 @@ for basic values, and doesn't specify import paths).
Django can serialize the following:
- ``int``, ``float``, ``bool``, ``str``, ``unicode``, ``bytes``, ``None``
- ``int``, ``float``, ``bool``, ``str``, ``bytes``, ``None``
- ``list``, ``set``, ``tuple``, ``dict``
- ``datetime.date``, ``datetime.time``, and ``datetime.datetime`` instances
(include those that are timezone-aware)