Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #72597
| Newsgroups | comp.lang.python |
|---|---|
| Date | 2014-06-03 22:36 -0700 |
| References | (2 earlier) <20140603194949.3147497d@x34f> <CAPTjJmrwGVaJKmzLiX8buZQmGxrGJV657Jnb7fsK7j1-pLxtVA@mail.gmail.com> <mailman.10646.1401831682.18130.python-list@python.org> <44acd692-5dcd-4e5f-8238-7fbe0de4db2a@googlegroups.com> <538eac94$0$11109$c3e8da3@news.astraweb.com> |
| Message-ID | <f0a2d25f-3480-4ebc-b41e-603a77b3451d@googlegroups.com> (permalink) |
| Subject | Re: Micro Python -- a lean and efficient implementation of Python 3 |
| From | Rustom Mody <rustompmody@gmail.com> |
On Wednesday, June 4, 2014 10:50:21 AM UTC+5:30, Steven D'Aprano wrote: > On Tue, 03 Jun 2014 20:37:27 -0700, Rustom Mody wrote: > > And so a pure BMP-supporting implementation may be a reasonable > > compromise. [As long as no surrogate-pairs are there] > At the cost on one extra bit, strings could use UTF-16 internally and > still have correct behaviour. The bit could be a flag recording whether > the string contains any surrogate pairs. If the flag was 0, all string > operations could assume a constant 2-bytes-per-character. If the flag was > 1, it could fall back to walking the string checking for surrogate pairs. Yes. That could be one possibility. My main reason in giving the 4-engine choice was not that 4 engines are a good idea but that in the very differently constrained world of μ-controllers playing around with alternate binding times may be advantageous > > On Wednesday, June 4, 2014 3:11:12 AM UTC+5:30, Paul Sokolovsky wrote: > >> With that in mind, I, as many others, think that forcing Unicode bloat > >> upon people by default is the most controversial feature of Python3. > >> The reason is that you go very long way dealing with languages of the > >> people of the world by just treating strings as consisting of 8-bit > >> data. I'd say, that's enough for 90% of applications. Unicode is needed > >> only if one needs to deal with multiple languages *at the same time*, > >> which is fairly rare (remaining 10% of apps). > >> And please keep in mind that MicroPython was originally intended (and > >> should be remain scalable down to) an MCU. Unicode needed there is even > >> less, and even less resources to support Unicode just because. > > At some time (when jmf was making more intelligible noises) I had > > suggested that the choice between 1/2/4 byte strings that happens at > > runtime in python3's FSR can be made at python-start time with a > > command-line switch. There are many combinations here; here is one in > > more detail: > > Instead of having one (FSR) string engine, you have (upto) 4 > > - a pure 1 byte (ASCII) > There are only 128 ASCII characters, so a pure ASCII implementation > cannot even represent arbitrary bytes. Yes this is a subtle point. I was initially going to write Latin-1. Wrote a rough-n-ready ASCII. But maybe it could be a choice. I really dont understand the binding-times of μ-controllers. My impression is that actual development is split 1 tinkering with the board 2 working on full powered computers and downloading to the board In going from 2 to 1 heavy amounts of cut-downs are probably possible and desirable. If this is the case, having hooks in the system for making choices may be a good idea optimal choices may be worthwhile
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