Blog "about python 3"

[Terry Reedy]

On 1/5/2014 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:
>>> 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.
...

> My examples are ONLY ILLUSTRATING, this FSR
> is wrong by design, can be on the side of
> memory, performance, linguistic or even
> typography.

Let me expand on 3 of my points. First, performance == time:

Point 3. You correctly identified a time regression in finding a 
character in a string. I saw that the slowdown was *not* inherent in the 
FSR but had to be a glitch in the code, and reported it on pydev with 
the hope that someone would fix it even if it were not too important in 
real use cases. Someone did.

Point 1. You incorrectly generalized that extreme case. I reported (a 
year ago last September) that the overall stringbench results were about 
the same. I also pointed out that there is an equally non-representative 
extreme case in the opposite direction, and that it would equally be 
wrong of me to use that to claim that FSR is faster. (It turns out that 
this FSR speed advantage *is* inherent in the design.)

Memory: Point 2. A *design goal* of FSR was to save memory relative  to 
UTF-32, which is what you apparently prefer. Your examples show that FSF 
successfully met its design goal. But you call that success, saving 
memory, 'wrong'. On what basis?

You *claim* the FSR is 'wrong by design', but your examples only show 
that is was temporarily wrong in implementation as far as speed and 
correct by design as far as memory goes.

-- 
Terry Jan Reedy