According to
<http://docs.python.org/dev/3.0/reference/lexical_analysis.html#id9\>,
raw strings with \u and \U escape sequences should have these sequences
parsed as usual. However, they are currently escaped.

>>> r'\u0020'
'\\u0020'

Expected:
>>> r'\u0020'
' '

You use the "ur" string mode.

>>> print ur"\u0020"
" "

No, it's about python 3.0. I confirm the problem, and propose a patch:

--- Python/ast.c.original       2008-04-03 15:12:15.548389400 +0200
+++ Python/ast.c        2008-04-03 15:12:28.359475800 +0200
@@ -3232,7 +3232,7 @@
             return NULL;
         }
     }
-    if (!*bytesmode && !rawmode) {
+    if (!*bytesmode) {
         return decode_unicode(s, len, rawmode, encoding);
     }
     if (*bytesmode) {

Thanks for noticing, Amaury, and your patch works for me.

Fixed in r62128.

Sorry, Guido said this is not allowed:
http://mail.python.org/pipermail/python-3000/2008-April/012952.html. I
reverted it in r62165.

The docs still need to be updated! An entry in what's new in 3.0 should
also be added.

How's this?

Instead of "ignored" (which might be read ambiguously) how about "not
treated specially"?

You also still need to add some words to whatsnew.

"not treated specially" it is!

The segment "use different rules for interpreting backslash escape
sequences." should be killed entirely, and the whole rule told here.

Also, a few paragraphs later there are more references to raw strings,
e.g. "When an 'r' or 'R' prefix is used in a string literal,"
which need to be fixed too.

I made the requested improvements and mentioned it in NEWS. Is there
worth putting in the tutorial, since it mentions Unicode strings and raw
strings?

What about the "raw-unicode-escape" codec?
Can we leave it different from raw strings literals?

To be honest, I don't know what the uses are for that codec.

pickle still uses it when protocol=0 (and cPickle as well, but in trunk/
only of course)

You can't change the codec - it's being used in other places as well,
e.g. for use cases where you need to have an 8-bit encoded readable
version of a Unicode object (which happens to be Latin-1 + Unicode
escapes for all non-Latin-1 characters, due to Unicode being a superset
of Latin-1).

Adding a new codec would be fine, though I don't know how this would map
raw Unicode strings with non-Latin-1 characters in them to an 8-bit
string. Perhaps this is not needed at all in Py3k.

Isn't "unicode-escape" enough for this purpose?

What do you mean with "enough" ?

The "raw-unicode-escape" codec is used in Python 2.x to convert literal
strings of the form ur"" to Unicode objects. It's a variant of the
"unicode-escape" codec.

The codec is also being used in cPickle, pickle, variants of pickle,
Python code generators, etc.

It serves its purpose, just like "unicode-escape" and all the other
codecs in Python.

I mean: now that raw strings cannot represent all unicode points (or
more precisely, they need the file encoding to do so), is there a use
case for "raw-unicode-escape" that cannot be filled by the
unicode-escape codec?

Note that pickle does not use "raw-unicode-escape" as is: it replaces
backslashes by \u005c. This has the nice effect that pickled strings can
also be decoded by "unicode-escape".

That's why I propose to completely remove raw-unicode-escape, and use
unicode-escape instead.

While that's true for cPickle, it is not for pickle. The pickle protocol
itself is defined in terms of the "raw-unicode-escape" codec (see
pickle.py).

Besides, you cannot assume that the Python interpreter itself is the
only use-case for these codecs. The "raw-unicode-escape" codec is well
usable for other purposes where you need a compact way of encoding
Unicode, especially if you're strings are mostly Latin-1 and only
include non-UCS2 code points every now and then. That's also the reason
why pickle uses it.

What is the status of this bug? AFAICT, the code is now correct. Have
the doc changes been applied? The resolution on this report should be
updated too. It's currently rejected.

It's rejected because the OP wanted unicode escapes to be applied in
unicode strings, and I haven't applied the docs because nobody has told
me I should.

Please apply the patch, but rename "Unicode escapes" to "\u and \U
escapes" first.

Fixed in r62568.