On Fri, Jun 06, 2014 at 12:51:11PM +1200, Greg Ewing wrote: > Steven D'Aprano wrote: > >(1) I asked if it would be okay for MicroPython to *optionally* use > >nominally Unicode strings limited to ASCII. Pretty much the only > >response to this as been Guido saying "That would be a pretty lousy > >option", > > It would be limiting to have this as the *only* way of > dealing with unicode, but I don't see anything wrong with > having this available as an option for applications that > truly don't need anything more than ascii. There must be > plenty of those; the controller that runs my car engine, > for example, doesn't exchange text with the outside world > at all.
I don't know about car engine controllers, but presumably they have diagnostic ports, and they may sometimes output text. If they output text, then at least hypothetically car mechanics in Russia might prefer their car to output "правда" and "ложный" rather than "true" and "false". I think that opportunities for ASCII-only optimizations are shrinking, not getting bigger, as more people come to expect that their computing devices speak their language rather than Foreign. > >The > >rationale of internal UTF-8 is that the use of any other encoding > >internally will be inefficient since those strings will need to be > >transcoded to UTF-8 before they can be written or printed, > > No, I think the rationale is that UTF-8 is likely to use > less memory than UTF-16 or UTF-32. Right. I was talking about memory efficiency. Instead of this, which requires two copies of the string at one time: 1) accept UTF-8 bytes 2) transcode to internal representation 3) discard UTF-8 bytes you could have: 1) accept UTF-8 bytes and be done. -- Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
