#13054: sys.maxunicode is now always 0x10FFFF.
diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
index acdde6d..43f65e2 100644
--- a/Doc/library/sys.rst
+++ b/Doc/library/sys.rst
@@ -625,9 +625,13 @@
.. data:: maxunicode
- An integer giving the largest supported code point for a Unicode character. The
- value of this depends on the configuration option that specifies whether Unicode
- characters are stored as UCS-2 or UCS-4.
+ An integer giving the value of the largest Unicode code point,
+ i.e. ``1114111`` (``0x10FFFF`` in hexadecimal).
+
+ .. versionchanged:: 3.3
+ Before :pep:`393`, :data:`sys.maxunicode` used to return either ``0xFFFF``
+ or ``0x10FFFF``, depending on the configuration option that specified
+ whether Unicode characters were stored as UCS-2 or UCS-4.
.. data:: meta_path
diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst
index 717e4e4..3cd4dd1 100644
--- a/Doc/whatsnew/3.3.rst
+++ b/Doc/whatsnew/3.3.rst
@@ -55,6 +55,17 @@
=============
+PEP 393: Flexible String Representation
+=======================================
+
+XXX Add list of changes introduced by :pep:`393` here:
+
+* The value of :data:`sys.maxunicode` is now always ``1114111`` (``0x10FFFF``
+ in hexadecimal). The :c:func:`PyUnicode_GetMax` function still returns
+ either ``0xFFFF`` or ``0x10FFFF`` for backward compatibility, and it should
+ not be used with the new Unicode API (see :issue:`13054`).
+
+
Other Language Changes
======================