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/2014-June/134833.html below:

[Python-Dev] Internal representation of strings and Micropython

[Python-Dev] Internal representation of strings and Micropython [Python-Dev] Internal representation of strings and MicropythonGreg Ewing greg.ewing at canterbury.ac.nz
Fri Jun 6 02:51:11 CEST 2014
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.

> 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.

-- 
Greg
More information about the Python-Dev mailing list

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