mirror of https://github.com/ansible/ansible.git
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.pull/29667/head
parent
362a2e523a
commit
ff13d58c14
@ -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.
|
||||||
|
|
||||||
@ -0,0 +1,16 @@
|
|||||||
|
#!/bin/sh
|
||||||
|
|
||||||
|
UNICODE_LITERALS_USERS=$(grep -r unicode_literals . \
|
||||||
|
--exclude-dir .git \
|
||||||
|
--exclude-dir .tox \
|
||||||
|
--exclude no-unicode-literals.sh \
|
||||||
|
--exclude no-unicode-literals.rst |
|
||||||
|
grep -v ./test/results \
|
||||||
|
)
|
||||||
|
|
||||||
|
if [ "${UNICODE_LITERALS_USERS}" ]; then
|
||||||
|
echo "${UNICODE_LITERALS_USERS}"
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
exit 0
|
||||||
Loading…
Reference in New Issue