Ein Rätsel:

$ cd test/ucs-test && ucslint
Process Process-1:
Traceback (most recent call last):
...
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 32-34: truncated \UXXXXXXXX escape

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
...
AttributeError: 'NoneType' object has no attribute 'rstrip'

Keine Idee? Hier der nächste Hinweis:

python3 -m flake8 tests/51_samba4/56evaluate_windows_gpo

mit dem selben Traceback.

Immer noch keine Idee? Den nächsten Hinweis bekommt man mit einem Blick in die Datei:

windows_set_gpo_registry_value(gpo_name,
 "HKCU\Software\Policies\Microsoft\UCSTestKey",
 "TestUserValueOne",
 "Foo",
 "String")

Immer noch nicht?

 "HKCU\Software\Policies\Microsoft\UCSTestKey"
                                  ^^12345678

\U........ ist eine Escape-Sequenz für String literals, um Unicode-Zeichen angeben zu können. Nach dem \U müssen exakt 8 Hex-Digits kommen – CSTestKe ist das nicht. (Der kleine Bruder wäre übrigend \u...., was nur 4 Hex-Zeichen erwartet.)

Doch warum tritt das nur mit Python 3 auf?

Nun, mit Python 3 ist unicode Standard. Da die beiden Escape-Sequenzen aber eben nur für Unicode-String (und nicht für Byte-Strings) aktiv sind, tritt das Problem erst mit Python 3 auf.

Merke

Zeichenketten, die den Backslash enthalten, sollten nach Möglichkeit als sog. Raw-String r"…\…" notiert werden. Das der Backlash sehr häufig in regulären Ausdrücken genutzt wird, ist es dort besonders wichtig.

PS: Ich habe ein Skript, was ich noch in ucslint integrieren will. flake8 liefert dafür eigentlich auch schon Invalid escape sequence ‚x‘ (W605), aber wenn es bei einer ungültigen Sequenz abstürzt, hilft einem das auch nicht viel weiter. Eine Korrektur von ucs-test habe ich bereits.

PPS: Und als Vorfreude auf UCS-5 basierend auf Debian 10 Buster mit Python 3.7 haben wir dann auch irgendwann mal Python 3.6 f-Strings.