mirror of
https://github.com/django/django.git
synced 2025-10-23 21:59:11 +00:00
Refs #23919 -- Removed python_2_unicode_compatible decorator usage
This commit is contained in:
@@ -228,10 +228,6 @@ Model style
|
||||
first_name = models.CharField(max_length=20)
|
||||
last_name = models.CharField(max_length=40)
|
||||
|
||||
* If you define a ``__str__`` method (previously ``__unicode__`` before Python 3
|
||||
was supported), decorate the model class with
|
||||
:func:`~django.utils.encoding.python_2_unicode_compatible`.
|
||||
|
||||
* The order of model inner classes and standard methods should be as
|
||||
follows (noting that these are not all required):
|
||||
|
||||
|
||||
@@ -452,15 +452,12 @@ of this object. Let's fix that by editing the ``Question`` model (in the
|
||||
:filename: polls/models.py
|
||||
|
||||
from django.db import models
|
||||
from django.utils.encoding import python_2_unicode_compatible
|
||||
|
||||
@python_2_unicode_compatible # only if you need to support Python 2
|
||||
class Question(models.Model):
|
||||
# ...
|
||||
def __str__(self):
|
||||
return self.question_text
|
||||
|
||||
@python_2_unicode_compatible # only if you need to support Python 2
|
||||
class Choice(models.Model):
|
||||
# ...
|
||||
def __str__(self):
|
||||
|
||||
@@ -601,9 +601,7 @@ representation of the model from the ``__str__()`` method.
|
||||
For example::
|
||||
|
||||
from django.db import models
|
||||
from django.utils.encoding import python_2_unicode_compatible
|
||||
|
||||
@python_2_unicode_compatible # only if you need to support Python 2
|
||||
class Person(models.Model):
|
||||
first_name = models.CharField(max_length=50)
|
||||
last_name = models.CharField(max_length=50)
|
||||
@@ -611,9 +609,6 @@ For example::
|
||||
def __str__(self):
|
||||
return '%s %s' % (self.first_name, self.last_name)
|
||||
|
||||
If you'd like compatibility with Python 2, you can decorate your model class
|
||||
with :func:`~django.utils.encoding.python_2_unicode_compatible` as shown above.
|
||||
|
||||
``__eq__()``
|
||||
------------
|
||||
|
||||
|
||||
@@ -258,33 +258,6 @@ 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.
|
||||
|
||||
Choosing between ``__str__()`` and ``__unicode__()``
|
||||
----------------------------------------------------
|
||||
|
||||
.. note::
|
||||
|
||||
If you are on Python 3, you can skip this section because you'll always
|
||||
create ``__str__()`` rather than ``__unicode__()``. If you'd like
|
||||
compatibility with Python 2, you can decorate your model class with
|
||||
:func:`~django.utils.encoding.python_2_unicode_compatible`.
|
||||
|
||||
One consequence of using Unicode by default is that you have to take some care
|
||||
when printing data from the model.
|
||||
|
||||
In particular, rather than giving your model a ``__str__()`` method, we
|
||||
recommended you implement a ``__unicode__()`` method. In the ``__unicode__()``
|
||||
method, you can quite safely return the values of all your fields without
|
||||
having to worry about whether they fit into a bytestring or not. (The way
|
||||
Python works, the result of ``__str__()`` is *always* a bytestring, even if you
|
||||
accidentally try to return a Unicode object).
|
||||
|
||||
You can still create a ``__str__()`` method on your models if you want, of
|
||||
course, but you shouldn't need to do this unless you have a good reason.
|
||||
Django's ``Model`` base class automatically provides a ``__str__()``
|
||||
implementation that calls ``__unicode__()`` and encodes the result into UTF-8.
|
||||
This means you'll normally only need to implement a ``__unicode__()`` method
|
||||
and let Django handle the coercion to a bytestring when required.
|
||||
|
||||
Taking care in ``get_absolute_url()``
|
||||
-------------------------------------
|
||||
|
||||
|
||||
@@ -148,27 +148,6 @@ In Python 3, there's simply :meth:`~object.__str__`, which must return ``str``
|
||||
(It is also possible to define :meth:`~object.__bytes__`, but Django applications
|
||||
have little use for that method, because they hardly ever deal with ``bytes``.)
|
||||
|
||||
Django provides a simple way to define :meth:`~object.__str__` and
|
||||
` __unicode__()`_ methods that work on Python 2 and 3: you must
|
||||
define a :meth:`~object.__str__` method returning text and to apply the
|
||||
:func:`~django.utils.encoding.python_2_unicode_compatible` decorator.
|
||||
|
||||
On Python 3, the decorator is a no-op. On Python 2, it defines appropriate
|
||||
` __unicode__()`_ and :meth:`~object.__str__` methods (replacing the
|
||||
original :meth:`~object.__str__` method in the process). Here's an example::
|
||||
|
||||
from __future__ import unicode_literals
|
||||
from django.utils.encoding import python_2_unicode_compatible
|
||||
|
||||
@python_2_unicode_compatible
|
||||
class MyClass(object):
|
||||
def __str__(self):
|
||||
return "Instance of my class"
|
||||
|
||||
This technique is the best match for Django's porting philosophy.
|
||||
|
||||
For forwards compatibility, this decorator is available as of Django 1.4.2.
|
||||
|
||||
Finally, note that :meth:`~object.__repr__` must return a ``str`` on all
|
||||
versions of Python.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user