Blog "about python 3"

[wxjmfauth at gmail.com]

Le dimanche 5 janvier 2014 23:14:07 UTC+1, Terry Reedy a écrit :
> 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.
> 
> 

Point 3: You are right. I'm very happy to agree.

Point 2: This Flexible String Representation does no
"effectuate" any memory optimization. It only succeeds
to do the opposite of what a corrrect usage of utf*
do.

Ned : this has already been explained and illustrated.

jmf