Refs #23919 -- Removed python_2_unicode_compatible decorator usage

5 files changed, 0 insertions, 60 deletions

diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index fe0a21c5a5..abed891d63 100644
--- a/docs/internals/contributing/writing-code/coding-style.txt
+++ b/docs/internals/contributing/writing-code/coding-style.txt
@@ -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):
 
diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt
index bd7e9c18ca..f7bf850309 100644
--- a/docs/intro/tutorial02.txt
+++ b/docs/intro/tutorial02.txt
@@ -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):
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index 83f76f37ca..838a4bd4de 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -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__()``
 ------------
 
diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt
index 3c29be550d..c167fd55b3 100644
--- a/docs/ref/unicode.txt
+++ b/docs/ref/unicode.txt
@@ -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()``
 -------------------------------------
 
diff --git a/docs/topics/python3.txt b/docs/topics/python3.txt
index 9dd4d83732..5b40f57bd3 100644
--- a/docs/topics/python3.txt
+++ b/docs/topics/python3.txt
@@ -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.