> 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. Haven't read Tim's post, but I agree to screw compatibility here, and I see two reasonable ways out: (1) \x takes up to 2 hex chars in 8-bit strings and up to 4 hex chars in Unicode. (2) \x takes up to 4 hex chars in all strings. The presence of -U and ease of JPython compatibility both suggest that (2) is best. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
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