A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-July/006719.html below:

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

[Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings?Fredrik Lundh Fredrik Lundh" <effbot@telia.com
Sun, 16 Jul 2000 20:34:29 +0200
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:=20

    "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? ;-)

> 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...

</F>




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