Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Sat, 25 Aug 2012 23:59:34 -0700 (PDT)
In-Reply-To: <mailman.3816.1345933655.4697.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=83.78.186.59; posting-account=ung4FAoAAAC46zhHJ0Nsnuox7M5gDvs_
References: <a81cd504-d889-4aa1-9daa-6df3448b4da8@googlegroups.com> <1874857c-68ef-4c1b-b15a-46ef47df9445@googlegroups.com> <mailman.3784.1345854291.4697.python-list@python.org> <1cb3f062-eb45-4b0c-977b-76afb099923c@googlegroups.com> <k1a40u$r47$2@ger.gmane.org> <mailman.3793.1345888006.4697.python-list@python.org> <f6266544-d67c-4589-a3ed-c14428ead237@googlegroups.com> <mailman.3816.1345933655.4697.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: Flexible string representation, unicode, typography, ...
From: wxjmfauth@gmail.com
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Python <python-list@python.org>
Precedence: list
Message-ID: <mailman.3831.1345964382.4697.python-list@python.org>
Lines: 80
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:27907

Le dimanche 26 ao=C3=BBt 2012 00:26:56 UTC+2, Ian a =C3=A9crit=C2=A0:
> On Sat, Aug 25, 2012 at 9:47 AM,  <wxjmfauth@gmail.com> wrote:
>=20
> > For those you do not know, the go language has introduced
>=20
> > the rune type. As far as I know, nobody is complaining, I
>=20
> > have not even seen a discussion related to this subject.
>=20
>=20
>=20
> Python has that also.  We call it "int".
>=20
>=20
>=20
> More seriously, strings in Go are not sequences of runes.  They're
>=20
> actually arrays of UTF-8 bytes.  That means that they're quite
>=20
> efficient for ASCII strings, at the expense of other characters, like
>=20
> Chinese (wait, this sounds familiar for some reason).  It also means
>=20
> that you have to bend over backwards if you want to work with actual
>=20
> runes instead of bytes.  Want to know how many characters are in your
>=20
> string?  Don't call len() on it -- that will only tell you how many
>=20
> bytes are in it.  Don't try to index or slice it either -- that will
>=20
> (accidentally) work for ASCII strings, but for other strings your
>=20
> indexes will be wrong.  If you're unlucky you might even split up the
>=20
> string in the middle of a character, and now your string has invalid
>=20
> characters in it.  The right way to do it looks something like this:
>=20
>=20
>=20
> len([]rune("=E7=99=BD=E9=B5=AC=E7=BF=94"))  // get the length of the stri=
ng in characters
>=20
> string([]rune("=E7=99=BD=E9=B5=AC=E7=BF=94")[0:2])  // get the substring =
containing the first
>=20
> two characters
>=20
>=20
>=20
> It reminds me of working in Python 2.X, except that instead of an
>=20
> actual unicode type you just have arrays of ints.


Sorry, you do not get it.

The rune is an alias for int32. A sequence of runes is a
sequence of int32's. Go do not spend its time in using a
machinery to work with, to differentiate, to keep in memory
this sequence according to the *characers* composing this
"array of code points".

The message is even stronger. Use runes to work comfortably [*]
with unicode:
rune -> int32 -> utf32 -> unicode (the perfect scheme, cann't be
better)

[*] Beyond my skill and my kwowloge and if I understood correctly,
this rune is even technically optimized to ensure it it always
an int32.

len() or slices() have nothing to do here.

My experience with go is equal to uero + epsilon.

jmf