Blog "about python 3"

[Ned Batchelder]

On 1/5/14 9:23 AM, wxjmfauth at gmail.com wrote:
> Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a écrit :
>> On 1/4/2014 2:10 PM, wxjmfauth at gmail.com wrote:
>>> I do not mind to be considered as an idiot, but
>>> I'm definitively not blind.
>>>
>>> And I could add, I *never* saw once one soul, who is
>>> explaining what I'm doing wrong in the gazillion
>>> of examples I gave on this list.
>>
>> If this is true, it is because you have ignored and not read my
>> numerous, relatively polite posts. To repeat very briefly:
>>
>> 1. Cherry picking (presenting the most extreme case as representative).
>>
>> 2. Calling space saving a problem (repeatedly).
>>
>> 3. Ignoring bug fixes.
>>
>> 4. Repetition (of the 'gazillion example' without new content).
>>
>> Have you ever acknowledged, let alone thank people for, the fix for the
>> one bad regression you did find. The FSR is still a work in progress.
>> Just today, Serhiy pushed a patch speeding up the UTF-32 encoder, after
>> previously speeding up the UTF-32 decoder.
>>
>> --
>
> My examples are ONLY ILLUSTRATING, this FSR
> is wrong by design, can be on the side of
> memory, performance, linguistic or even
> typography.

JMF: this has been pointed out to you time and again: the flexible 
string representation is not wrong.  To show that it is wrong, you would 
have to demonstrate some semantic of Unicode that is violated.  You have 
never done this.  You've picked pathological cases and shown 
micro-timing output, and memory usage.  The Unicode standard doesn't 
promise anything about timing or memory use.

The FSR makes a trade-off of time and space.  Everyone but you considers 
it a good trade-off.  I don't think you are showing real use cases, but 
if they are, I'm sorry that your use-case suffers.  That doesn't make 
the FSR wrong. The most accurate statement is that you don't like the 
FSR.  That's fine, you're entitled to your opinion.

You say the FSR is wrong linguistically.  This can't be true, since an 
FSR Unicode string is indistinguishable from an internally-UTF-32 
Unicode string, and no, memory use or timings are irrelevant when 
discussing the linguistic performance of a Unicode string.

You've also said that the internal representation of the FSR is 
incorrect because of encodings somehow.  Encodings have nothing to do 
with the internal representation of a Unicode string, they are for 
interchanging data.  You seem to know a lot about Unicode, but when you 
make this fundamental mistake, you call all of your expertise into question.

To re-iterate what you are doing wrong:

1) You continue to claim things that are not true, and that you have 
never substantiated.

2) You paste code samples without accompanying text that explain what 
you are trying to demonstrate.

3) You ignore refutations that disprove your points.

These are all the behaviors of a troll.  Please stop.

If you want to discuss the details of Unicode implementations, I'd 
welcome an offlist discussion, but only if you will approach it honestly 
enough to leave open the possibility that you are wrong.  I know I would 
be glad to learn details of Unicode that I have missed, but so far you 
haven't provided any.

--Ned.

>
> I will not refrain you to waste your time
> in adjusting bytes, if the problem is not
> on that side.
>
> jmf
>


-- 
Ned Batchelder, http://nedbatchelder.com