Fredrik Lundh wrote: > > mal wrote: > > > There were objections from Finn Bock and myself: \xXXXX is > > defined to mean "read all hex chars until the next non-hex char > > and then cast to the underlying type (char or wchar_t)" in C9X. > > finn wrote: > > "the implementation of \x in JPython is so full of bugs > and inconsistencies that I'm +1 on your proposal." > > since when is +1 an objection? ;-) Ooops, I must have overlooked that one. > > Not that this definition is optimal, but we should stick to what > > the standard says and only depreciate usage of \xXXXX in favour > > of \uXXXX. Code using escapes like "\xABCD" which then results > > in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" > > wouldn't make much of a difference (+ the bug would become pretty > > obvious if viewed in a Unicode aware viewer: Asian characters are > > very easy to recognize in ASCII text ;-) > > as Tim pointed out in the SRE thread, the only standard that > means something here is Python 1.5.2. And in Python 1.5.2, > \u means read as many hex digits as you can, and cast the > result to a character. > > I'd say it's more important to be compatible with Python (1.5.2 > string literals, SRE regular expression literals), than to be com- > patible with C9X... Ok, ok, go ahead :-) (please also update the docs, if there are any on this subject -- a grep didn't show anything up on \xXXX) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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