Movatterモバイル変換
[0]ホーム
[Python-Dev] Internal representation of strings and Micropython
Paul Sokolovskypmiscml at gmail.com
Wed Jun 4 12:53:14 CEST 2014
Hello,On Tue, 3 Jun 2014 22:23:07 -0700Guido van Rossum <guido at python.org> wrote:[]> Never mind disabling assertions -- even with enabled assertions you'd> have to expect most Python programs to fail with non-ASCII input.>> Then again the UTF-8 option would be pretty devastating too for> anything manipulating strings (especially since many Python APIs are> defined using indexes, e.g. the re module).If the Unicode is slow (*), then obvious choice is not using Unicodewhen not needed. Too bad that's a bit hard in Python3, as it enforcesUnicode everywhere, and dealing with efficient strings requiresprefixing them with funny characters like "b", etc.* If Unicode if slow because it causes heap to bloat and go swap, thechoice is still the same.>> Why not support variable-width strings like CPython 3.4?Because, like good deal of community, we hope that Python4 will getback to reality, and strings will be efficient (both for processing andstorage) by default, and niche and marginal "Unicode string" type willbe used explicitly (using funny prefixes, etc.), only when reallyneeded.Ah, all these not so funny geek jokes about internals of languageimplementation, hope they didn't make somebody's day dull!>> --> --Guido van Rossum (python.org/~guido)-- Best regards, Paul mailto:pmiscml at gmail.com
More information about the Python-Devmailing list
[8]ページ先頭