On 1/8/2014 4:59 AM, wxjmfa...@gmail.com wrote: [responding to me]
The FSR acts more as an coding scheme selector
That is what PEP 393 describes and what I and many others have said. The FSR saves memory by selecting from three choices the most compact coding scheme for each string.
I ask again, have you read PEP 393? If you are going to critique the FSR, you should read its basic document.
> than as a code point optimizer. I do not know what you mean by 'code point optimizer'.
Claiming that it saves memory is some kind of illusion;
Do you really think that the mathematical fact "10026 < 20040 < 40044" (from your example below) is some kind of illusion? If so, please take your claim to a metaphysics list. If not, please stop trolling.
a little bit as saying "Py2.7 uses "relatively" less memory than Py3.2 (UCS-2)".
This is inane as 2.7 and 3.2 both use the same two coding schemes. Saying '1 < 2' is different from saying '2 < 2'.
On 3.3+
sys.getsizeof('a' * 10000 + 'z')10026sys.getsizeof('a' * 10000 + '€')20040sys.getsizeof('a' * 10000 + '\U00010000')40044
3.2- wide (UCS-4) builds use about 40050 bytes for all three unicode strings. One again, you have posted examples that show how FSR saves memory, thus negating your denial of the saving.
-- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
