Fixed #18269 -- Applied unicode_literals for Python 3 compatibility.

Thanks Vinay Sajip for the support of his django3 branch and
Jannis Leidel for the review.

docs/conf.py

@@ -11,6 +11,8 @@
 # All configuration values have a default; values that are commented out
 # serve to show the default.
 
+from __future__ import unicode_literals
+
 import sys
 import os
 
@@ -197,8 +199,8 @@ modindex_common_prefix = ["django."]
 # (source start file, target name, title, author, document class [howto/manual]).
 #latex_documents = []
 latex_documents = [
-  ('contents', 'django.tex', u'Django Documentation',
-   u'Django Software Foundation', 'manual'),
+  ('contents', 'django.tex', 'Django Documentation',
+   'Django Software Foundation', 'manual'),
 ]
 
 # The name of an image file (relative to this directory) to place at the top of
@@ -237,10 +239,10 @@ man_pages = [
 # -- Options for Epub output ---------------------------------------------------
 
 # Bibliographic Dublin Core info.
-epub_title = u'Django'
-epub_author = u'Django Software Foundation'
-epub_publisher = u'Django Software Foundation'
-epub_copyright = u'2010, Django Software Foundation'
+epub_title = 'Django'
+epub_author = 'Django Software Foundation'
+epub_publisher = 'Django Software Foundation'
+epub_copyright = '2010, Django Software Foundation'
 
 # The language of the text. It defaults to the language option
 # or en if the language is not set.

docs/ref/files/file.txt

@@ -94,10 +94,11 @@ The ``ContentFile`` Class
     but unlike :class:`~django.core.files.File` it operates on string content,
     rather than an actual file. For example::
 
+        from __future__ import unicode_literals
         from django.core.files.base import ContentFile
 
         f1 = ContentFile(b"my string content")
-        f2 = ContentFile(u"my unicode content encoded as UTF-8".encode('UTF-8'))
+        f2 = ContentFile("my unicode content encoded as UTF-8".encode('UTF-8'))
 
 .. currentmodule:: django.core.files.images
 

docs/ref/forms/fields.txt

@@ -25,8 +25,6 @@ exception or returns the clean value::
     >>> f = forms.EmailField()
     >>> f.clean('foo@example.com')
     u'foo@example.com'
-    >>> f.clean(u'foo@example.com')
-    u'foo@example.com'
     >>> f.clean('invalid email address')
     Traceback (most recent call last):
     ...

docs/ref/forms/validation.txt

@@ -184,7 +184,7 @@ a look at Django's ``EmailField``::
 
     class EmailField(CharField):
         default_error_messages = {
-            'invalid': _(u'Enter a valid e-mail address.'),
+            'invalid': _('Enter a valid e-mail address.'),
         }
         default_validators = [validators.validate_email]
 
@@ -197,7 +197,7 @@ on field definition so::
 is equivalent to::
 
     email = forms.CharField(validators=[validators.validate_email],
-            error_messages={'invalid': _(u'Enter a valid e-mail address.')})
+            error_messages={'invalid': _('Enter a valid e-mail address.')})
 
 
 Form field default cleaning

docs/ref/unicode.txt

@@ -45,6 +45,28 @@ rendering or anywhere else -- you have two choices for encoding those strings.
 You can use Unicode strings, or you can use normal strings (sometimes called
 "bytestrings") that are encoded using UTF-8.
 
+.. versionchanged:: 1.5
+
+In Python 3, the logic is reversed, that is normal strings are Unicode, and
+when you want to specifically create a bytestring, you have to prefix the
+string with a 'b'. As we are doing in Django code from version 1.5,
+we recommend that you import ``unicode_literals`` from the __future__ library
+in your code. Then, when you specifically want to create a bytestring literal,
+prefix the string with 'b'.
+
+Python 2 legacy::
+
+    my_string = "This is a bytestring"
+    my_unicode = u"This is an Unicode string"
+
+Python 2 with unicode literals or Python 3::
+
+    from __future__ import unicode_literals
+
+    my_string = b"This is a bytestring"
+    my_unicode = "This is an Unicode string"
+    
+
 .. admonition:: Warning
 
     A bytestring does not carry any information with it about its encoding.
@@ -182,7 +204,7 @@ An example might clarify things here::
 
     >>> urlquote(u'Paris & Orléans')
     u'Paris%20%26%20Orl%C3%A9ans'
-    >>> iri_to_uri(u'/favorites/François/%s' % urlquote(u'Paris & Orléans'))
+    >>> iri_to_uri(u'/favorites/François/%s' % urlquote('Paris & Orléans'))
     '/favorites/Fran%C3%A7ois/Paris%20%26%20Orl%C3%A9ans'
 
 If you look carefully, you can see that the portion that was generated by
@@ -268,7 +290,9 @@ You can pass either Unicode strings or UTF-8 bytestrings as arguments to
 ``filter()`` methods and the like in the database API. The following two
 querysets are identical::
 
-    qs = People.objects.filter(name__contains=u'Å')
+    from __future__ import unicode_literals
+
+    qs = People.objects.filter(name__contains='Å')
     qs = People.objects.filter(name__contains=b'\xc3\x85') # UTF-8 encoding of Å
 
 Templates
@@ -276,9 +300,10 @@ Templates
 
 You can use either Unicode or bytestrings when creating templates manually::
 
-	from django.template import Template
-	t1 = Template(b'This is a bytestring template.')
-	t2 = Template(u'This is a Unicode template.')
+    from __future__ import unicode_literals
+    from django.template import Template
+    t1 = Template(b'This is a bytestring template.')
+    t2 = Template('This is a Unicode 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.
@@ -316,14 +341,15 @@ characters.
 The following code example demonstrates that everything except email addresses
 can be non-ASCII::
 
+    from __future__ import unicode_literals
     from django.core.mail import EmailMessage
 
-    subject = u'My visit to Sør-Trøndelag'
-    sender = u'Arnbjörg Ráðormsdóttir <arnbjorg@example.com>'
+    subject = 'My visit to Sør-Trøndelag'
+    sender = 'Arnbjörg Ráðormsdóttir <arnbjorg@example.com>'
     recipients = ['Fred <fred@example.com']
-    body = u'...'
+    body = '...'
     msg = EmailMessage(subject, body, sender, recipients)
-    msg.attach(u"Une pièce jointe.pdf", "%PDF-1.4.%...", mimetype="application/pdf")
+    msg.attach("Une pièce jointe.pdf", "%PDF-1.4.%...", mimetype="application/pdf")
     msg.send()
 
 Form submission

docs/topics/db/models.txt

@@ -156,11 +156,11 @@ ones:
     A choices list looks like this::
 
         YEAR_IN_SCHOOL_CHOICES = (
-            (u'FR', u'Freshman'),
-            (u'SO', u'Sophomore'),
-            (u'JR', u'Junior'),
-            (u'SR', u'Senior'),
-            (u'GR', u'Graduate'),
+            ('FR', 'Freshman'),
+            ('SO', 'Sophomore'),
+            ('JR', 'Junior'),
+            ('SR', 'Senior'),
+            ('GR', 'Graduate'),
         )
 
     The first element in each tuple is the value that will be stored in the
@@ -173,9 +173,9 @@ ones:
 
         class Person(models.Model):
             SHIRT_SIZES = (
-                (u'S', u'Small'),
-                (u'M', u'Medium'),
-                (u'L', u'Large'),
+                ('S', 'Small'),
+                ('M', 'Medium'),
+                ('L', 'Large'),
             )
             name = models.CharField(max_length=60)
             shirt_size = models.CharField(max_length=2, choices=SHIRT_SIZES)

docs/topics/i18n/translation.txt

@@ -416,8 +416,8 @@ result is included in a string. For example::
 
     from django.utils.translation import string_concat
     ...
-    name = ugettext_lazy(u'John Lennon')
-    instrument = ugettext_lazy(u'guitar')
+    name = ugettext_lazy('John Lennon')
+    instrument = ugettext_lazy('guitar')
     result = string_concat(name, ': ', instrument)
 
 In this case, the lazy translations in ``result`` will only be converted to