[Python-Dev] should we keep the \xnnnn escape in unicode strings?

[Thomas Wouters]

On Sun, Jul 16, 2000 at 02:19:22PM -0700, Greg Stein wrote:
> To me, this says punt the \x construct from Unicode objects altogether. If
> it is broken, then why try to retain it?

> I *do* find it useful in the regular string objects. For Unicode, I would
> totally understand needing to use \u instead.

Don't forget the -U option to python, which turns all strings into Unicode
strings. So it's broken now, that's no reason to break it some more ;) I
also thought the long-term idea was to make all strings unicode strings.
Making the two strings different in more than implementation is probably a
bad idea.

I'm with Tim here: screw the retarded compatibility. Make \x make sense in
normal strings and unicode strings both, but in a way that breaks as little
as possible: if it always results in one byte in 8bit strings, it should do
the same, IMHO, in unicode strings. I'm also for making \x take at most four
bytes, like the documentation states, instead of hassling with a perl-like
construct such as C has. I would be very, very suprised if anyone was using
\x29E8F28DA727 and expects it to work like \x27. 

We can use the beta cycle to see if it breaks anything.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!