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/2002-March/021763.html below:

PEP 263 phase 2 implementation (Re: [Python-Dev] PEP 263 considered faulty (for some Japanese))

PEP 263 phase 2 implementation (Re: [Python-Dev] PEP 263 considered faulty (for some Japanese)) PEP 263 phase 2 implementation (Re: [Python-Dev] PEP 263 considered faulty (for some Japanese))SUZUKI Hisao suzuki611@oki.com
Tue, 26 Mar 2002 09:02:15 +0900
> > N.B. one should write a binary (not character, but, say, image
> > or audio) data literal as follows:
> > 
> > 	b = '\x89\xAB\xCD\xEF'
> 
> I completely agree. Binary data should use hex escapes. That will make
> an interesting challenge for any stage 2 implementation, BTW: \xAB
> shall denote byte 0x89 no matter what the input encoding was. So you
> cannot convert \xAB to a Unicode character, and expect conversion to
> the input encoding to do the right thing. Instead, you must apply the
> conversion to the source encoding only for the unescaped characters.

Note that it is _not_ a challenge for my implementation at all.
You can use your binary strings as they are at present.  Please
try it.

> People had been proposing to introduce b'' strings for binary data, to
> allow to switch 'plain' strings to denote Unicode strings at some
> point, but this is a different PEP.

I think you need not introduce b'' strings at all; you can keep
it simple as it is.

--
SUZUKI Hisao <suzuki@acm.org> <suzuki611@oki.com>



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