Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Blog "about python 3"
Date: Sun, 05 Jan 2014 17:14:07 -0500
References: <mailman.4724.1388432539.18130.python-list@python.org> <52c1dc4c$0$2877$c3e8da3$76491128@news.astraweb.com> <l9soij$ck6$1@ger.gmane.org> <52C1F5EC.3020808@stoneleaf.us> <mailman.4748.1388478161.18130.python-list@python.org> <52c29416$0$29987$c3e8da3$5496439d@news.astraweb.com> <mailman.4753.1388499265.18130.python-list@python.org> <roy-4C0A2F.10412731122013@news.panix.com> <mailman.4797.1388684229.18130.python-list@python.org> <52c6415c$0$29972$c3e8da3$5496439d@news.astraweb.com> <la5u8j$hqr$1@ger.gmane.org> <52C6AD00.5050000@chamonix.reportlab.co.uk> <la7btn$u5$1@ger.gmane.org> <mailman.4882.1388808283.18130.python-list@python.org> <roy-1820F1.08551004012014@news.panix.com> <mailman.4905.1388845063.18130.python-list@python.org> <3519f85e-0909-4f5a-9a6e-09b6fd4c312d@googlegroups.com> <mailman.4915.1388875627.18130.python-list@python.org> <d8438ee4-1429-4855-9d78-b833f4f2748f@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <d8438ee4-1429-4855-9d78-b833f4f2748f@googlegroups.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.4976.1388960067.18130.python-list@python.org>
Lines: 52
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63232

On 1/5/2014 9:23 AM, wxjmfauth@gmail.com wrote:
> Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a =C3=A9crit :
>> On 1/4/2014 2:10 PM, wxjmfauth@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)=
=2E
>> 2. Calling space saving a problem (repeatedly).
 >> 3. Ignoring bug fixes.
=2E..

> 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 =3D=3D time:

Point 3. You correctly identified a time regression in finding a=20
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=20
the hope that someone would fix it even if it were not too important in=20
real use cases. Someone did.

Point 1. You incorrectly generalized that extreme case. I reported (a=20
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=20
wrong of me to use that to claim that FSR is faster. (It turns out that=20
this FSR speed advantage *is* inherent in the design.)

Memory: Point 2. A *design goal* of FSR was to save memory relative  to=20
UTF-32, which is what you apparently prefer. Your examples show that FSF =

successfully met its design goal. But you call that success, saving=20
memory, 'wrong'. On what basis?

You *claim* the FSR is 'wrong by design', but your examples only show=20
that is was temporarily wrong in implementation as far as speed and=20
correct by design as far as memory goes.

--=20
Terry Jan Reedy