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!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4