In 2.x, \uDDDD and \UDDDDDDDD are interpreted as Unicode escapes in
raw Unicode strings. That was a mistake, but we can't fix it (except
when using "from __future__ import unicode_literals"). In 3.0, \u or
\U in a raw string should have no special meaning -- it's just a
backslash followed by 'u' or 'U'.

This was fixed in 3.0a3. It seems to have reverted to the old (2.x)
behavior in 3.0a4.

THIS MUST BE FIXED!

fixed in r62165.

The was not a mistake, it was done on purpose since there would
otherwise have been no way to add non-ASCII Unicode code points to a raw
Unicode literal, rendering raw Unicode literals pretty useless.

Even if you use UTF-8 as source code encoding, there's no way to add
half a surrogate to a raw Unicode literal without the Unicode literals.

If you need to write a Unicode literal escape using the raw Unicode
escape encoding, you can use '\x1234'.

We went over this before. *I* consider the 2.x behavior a mistake, and
a decision was made to change in 3.0. It got much worse in 3.0 because
all literals are Unicode (except byte literals).

To add a unicode value to a raw string, just concatenate a raw string
and a non-raw string, e.g.

r'whatever' '\u1234' r'whatever'

I don't understand what you meant by '\x1234' -- the \x escape only
accepts 2 hex digits.