Le dimanche 5 janvier 2014 23:14:07 UTC+1, Terry Reedy a écrit : > On 1/5/2014 9:23 AM, wxjmfa...@gmail.com wrote: > > > Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a écrit : > > >> On 1/4/2014 2:10 PM, wxjmfa...@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 -- https://mail.python.org/mailman/listinfo/python-list
