Remove use of unicode_literals as it is an anti-pattern

from __future__ unicode_literals leads to developer confusion as
developers no longer can tell whether a bare literal string is a byte
string or a unicode string.  Explicit marking as u"" or b"" is the way
to solve the same problem in the Ansbile codebase.

(cherry picked from commit ff13d58c1443aeb3a59e224f73ab82b52230c6ff)

1 files changed, 16 insertions, 0 deletions

diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst
new file mode 100644
index 0000000000..fefa72c307
--- /dev/null
+++ b/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst
@@ -0,0 +1,16 @@
+Sanity Tests » no-unicode_literals
+==================================
+
+The use of :code:`from __future__ import unicode_literals` has been deemed an anti-pattern.  The
+problems with it are:
+
+* It makes it so one can't jump into the middle of a file and know whether a bare literal string is
+  a byte string or text string.  The programmer has to first check the top of the file to see if the
+  import is there.
+* It removes the ability to define native strings (a string which should be a byte string on python2
+  and a text string on python3) via a string literal.
+* It makes for more context switching.  A programmer could be reading one file which has
+  `unicode_literals` and know that bare string literals are text strings but then switch to another
+  file (perhaps tracing program execution into a third party library) and have to switch their
+  understanding of what bare string literals are.
+