Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #73080
| Newsgroups | comp.lang.python |
|---|---|
| Date | 2014-06-10 02:13 -0700 |
| References | (9 earlier) <538ecdef$0$11109$c3e8da3@news.astraweb.com> <7xoay9w1h0.fsf@ruckus.brouhaha.com> <20140604060152.2cdf8198@bigbox.christie.dr> <mailman.10699.1401882811.18130.python-list@python.org> <0a6ebce7-aa3f-4374-a0a1-004e421a2e15@googlegroups.com> |
| Message-ID | <0f0a2fbe-48df-46e0-a9a0-65896f02e22c@googlegroups.com> (permalink) |
| Subject | Re: Micro Python -- a lean and efficient implementation of Python 3 |
| From | wxjmfauth@gmail.com |
Le mardi 10 juin 2014 09:32:34 UTC+2, wxjm...@gmail.com a écrit :
> Le mercredi 4 juin 2014 13:53:19 UTC+2, Robin Becker a écrit :
>
> > On 04/06/2014 12:01, Tim Chase wrote:
>
> >
>
> > > On 2014-06-04 00:58, Paul Rubin wrote:
>
> >
>
> > >> Steven D'Aprano <steve@pearwood.info> writes:
>
> >
>
> > >>>> Maybe there's a use-case for a microcontroller that works in
>
> >
>
> > >>>> ISO-8859-5 natively, thus using only eight bits per character,
>
> >
>
> > >>> That won't even make the Russians happy, since in Russia there
>
> >
>
> > >>> are multiple incompatible legacy encodings.
>
> >
>
> > >>
>
> >
>
> > >> I've never understood why not use UTF-8 for everything.
>
> >
>
> > >
>
> >
>
> > > If you use UTF-8 for everything, then you end up in a world where
>
> >
>
> > > string-indexing (see ChrisA's other side thread on this topic) is no
>
> >
>
> > > longer an O(1) operation, but an O(N) operation. Some of us slice
>
> >
>
> > > strings for a living. ;-) I understand that using UTF-32 would allow
>
> >
>
> > > us to maintain O(1) indexing at the cost of every string occupying 4
>
> >
>
> > > bytes per character. The FSR (again, as I understand it) allows
>
> >
>
> > > strings that fit in one-byte-per-character to use that, scaling up to
>
> >
>
> > > use wider characters internally as they're actually needed/used.
>
> >
>
> > >
>
> >
>
> > ........
>
> >
>
> > I believe that we should distinguish between glyph/character indexing and string
>
> >
>
> > indexing. Even in unicode it may be hard to decide where a visual glyph starts
>
> >
>
> > and ends. I assume most people would like to assign one glyph to one unicode,
>
> >
>
> > but that's not always possible with composed glyphs.
>
> >
>
> >
>
> >
>
> > >>> for a in (u'\xc5',u'A\u030a'):
>
> >
>
> > ... for o in (u'\xf6',u'o\u0308'):
>
> >
>
> > ... u=a+u'ngstr'+o+u'm'
>
> >
>
> > ... print("%s %s" % (repr(u),u))
>
> >
>
> > ...
>
> >
>
> > u'\xc5ngstr\xf6m' Ångström
>
> >
>
> > u'\xc5ngstro\u0308m' Ångström
>
> >
>
> > u'A\u030angstr\xf6m' Ångström
>
> >
>
> > u'A\u030angstro\u0308m' Ångström
>
> >
>
> > >>> u'\xc5ngstr\xf6m'==u'\xc5ngstro\u0308m'
>
> >
>
> > False
>
> >
>
> >
>
> >
>
> > so even unicode doesn't always allow for O(1) glyph indexing. I know this is
>
> >
>
> > artificial, but this is the same situation as utf8 faces just the frequency of
>
> >
>
> > occurrence is different. A very large amount of computing is still western
>
> >
>
> > centric so searching a byte string for latin characters is still efficient;
>
> >
>
> > searching for an n with a tilde on top might not be so easy.
>
> >
>
> > --
>
> >
>
> > Robin Becker
>
>
>
> =========
>
>
>
> Python succeeded to become an anti-unicode product!
>
>
>
> jmf
-----
And deeply buggy!
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Micro Python -- a lean and efficient implementation of Python 3 Paul Sokolovsky <pmiscml@gmail.com> - 2014-06-04 00:41 +0300
Re: Micro Python -- a lean and efficient implementation of Python 3 Rustom Mody <rustompmody@gmail.com> - 2014-06-03 20:37 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 Chris Angelico <rosuav@gmail.com> - 2014-06-04 13:52 +1000
Re: Micro Python -- a lean and efficient implementation of Python 3 Rustom Mody <rustompmody@gmail.com> - 2014-06-03 21:40 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-03 23:02 -0600
Re: Micro Python -- a lean and efficient implementation of Python 3 Chris Angelico <rosuav@gmail.com> - 2014-06-04 17:16 +1000
Re: Micro Python -- a lean and efficient implementation of Python 3 Steven D'Aprano <steve@pearwood.info> - 2014-06-04 07:42 +0000
Re: Micro Python -- a lean and efficient implementation of Python 3 Paul Rubin <no.email@nospam.invalid> - 2014-06-04 00:58 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 Robin Becker <robin@reportlab.com> - 2014-06-04 11:06 +0100
Re: Micro Python -- a lean and efficient implementation of Python 3 Tim Chase <python.list@tim.thechases.com> - 2014-06-04 06:01 -0500
Re: Micro Python -- a lean and efficient implementation of Python 3 Marko Rauhamaa <marko@pacujo.net> - 2014-06-04 14:57 +0300
Re: Micro Python -- a lean and efficient implementation of Python 3 Tim Chase <python.list@tim.thechases.com> - 2014-06-04 07:25 -0500
Re: Micro Python -- a lean and efficient implementation of Python 3 Paul Rubin <no.email@nospam.invalid> - 2014-06-04 11:25 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 Robin Becker <robin@reportlab.com> - 2014-06-04 12:53 +0100
Re: Micro Python -- a lean and efficient implementation of Python 3 Marko Rauhamaa <marko@pacujo.net> - 2014-06-04 15:17 +0300
Re: Micro Python -- a lean and efficient implementation of Python 3 Robin Becker <robin@reportlab.com> - 2014-06-04 13:31 +0100
Re: Micro Python -- a lean and efficient implementation of Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-04 13:51 +0000
Re: Micro Python -- a lean and efficient implementation of Python 3 wxjmfauth@gmail.com - 2014-06-10 00:32 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 wxjmfauth@gmail.com - 2014-06-10 02:13 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 Tim Chase <python.list@tim.thechases.com> - 2014-06-04 07:21 -0500
Re: Micro Python -- a lean and efficient implementation of Python 3 Travis Griggs <travisgriggs@gmail.com> - 2014-06-06 09:59 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 Roy Smith <roy@panix.com> - 2014-06-06 13:29 -0400
Re: Micro Python -- a lean and efficient implementation of Python 3 Tim Chase <python.list@tim.thechases.com> - 2014-06-06 21:20 -0500
Re: Micro Python -- a lean and efficient implementation of Python 3 wxjmfauth@gmail.com - 2014-06-10 12:27 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 Chris Angelico <rosuav@gmail.com> - 2014-06-04 17:20 +1000
Re: Micro Python -- a lean and efficient implementation of Python 3 Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> - 2014-06-04 10:00 +0200
Re: Micro Python -- a lean and efficient implementation of Python 3 Roy Smith <roy@panix.com> - 2014-06-04 14:42 -0400
Re: Micro Python -- a lean and efficient implementation of Python 3 Rustom Mody <rustompmody@gmail.com> - 2014-06-04 19:06 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 Roy Smith <roy@panix.com> - 2014-06-05 09:59 -0400
Re: Micro Python -- a lean and efficient implementation of Python 3 Chris Angelico <rosuav@gmail.com> - 2014-06-06 01:33 +1000
Re: Micro Python -- a lean and efficient implementation of Python 3 Steven D'Aprano <steve@pearwood.info> - 2014-06-04 05:20 +0000
Re: Micro Python -- a lean and efficient implementation of Python 3 Rustom Mody <rustompmody@gmail.com> - 2014-06-03 22:36 -0700
Re: Micro Python -- a lean and efficient implementation of Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-03 23:55 -0600
Re: Micro Python -- a lean and efficient implementation of Python 3 Terry Reedy <tjreedy@udel.edu> - 2014-06-04 03:00 -0400
Re: Micro Python -- a lean and efficient implementation of Python 3 Chris Angelico <rosuav@gmail.com> - 2014-06-04 17:10 +1000
csiph-web