Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!eweka.nl!lightspeed.eweka.nl!194.134.4.91.MISMATCH!news2.euro.net!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: Py 3.3, unicode / upper()
Date: Thu, 20 Dec 2012 00:32:42 -0500
References: <2adb4a25-8ea3-441f-b8c0-ee6c87e4b19f@googlegroups.com> <kaslsb$iue$1@news.albasani.net> <CAPTjJmrLAe0i9rW6sCYkYBvpiPk2O=FHB0PgSq1dqNqh9Y7Zqg@mail.gmail.com> <CALwzid=jnj5LGcUXisj1U7bV_khfYrX+VH0BLswYoqX8bg9OpQ@mail.gmail.com> <CAPTjJmpmLubSUX+uDgP48Hme7gV=OvHHMKZ6izCAnW-z7Cr88w@mail.gmail.com> <katul2$5qo$1@ger.gmane.org> <20121220031223.GB12012@Kubrick>
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:17.0) Gecko/17.0 Thunderbird/17.0
In-Reply-To: <20121220031223.GB12012@Kubrick>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1091.1355981588.29569.python-list@python.org>
Lines: 59
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:35180

On 12/19/2012 10:12 PM, Westley Mart=C3=ADnez wrote:
> On Wed, Dec 19, 2012 at 09:54:20PM -0500, Terry Reedy wrote:
>> On 12/19/2012 9:03 PM, Chris Angelico wrote:
>>> On Thu, Dec 20, 2012 at 5:27 AM, Ian Kelly <ian.g.kelly@gmail.com> wr=
ote:
>>>>  From what I've been able to discern, [jmf's] actual complaint about=
 PEP
>>>> 393 stems from misguided moral concerns.  With PEP-393, strings that=

>>>> can be fully represented in Latin-1 can be stored in half the space
>>>> (ignoring fixed overhead) compared to strings containing at least on=
e
>>>> non-Latin-1 character.  jmf thinks this optimization is unfair to
>>>> non-English users and immoral; he wants Latin-1 strings to be treate=
d
>>>> exactly like non-Latin-1 strings (I don't think he actually cares
>>>> about non-BMP strings at all; if narrow-build Unicode is good enough=

>>>> for him, then it must be good enough for everybody).
>>>
>>> Not entirely; most of his complaints are based on performance (speed
>>> and/or memory) of 3.3 compared to a narrow build of 3.2, using silly
>>> edge cases to prove how much worse 3.3 is, while utterly ignoring the=

>>> fact that, in those self-same edge cases, 3.2 is buggy.
>>
>> And the fact that stringbench.py is overall about as fast with 3.3
>> as with 3.2 *on the same Windows 7 machine* (which uses narrow build
>> in 3.2), and that unicode operations are not far from bytes
>> operations when the same thing can be done with both.
>>
>> --
>> Terry Jan Reedy
>
> Really, why should we be so obsessed with speed anyways?  Isn't
> improving the language and fixing bugs far more important?

Being conservative, there are probably at least 10 enhancement patches=20
and 30 bug fix patches for every performance patch. Performance patches=20
are considered enhancements and only go in new versions with=20
enhancements, where they go through the extended alpha, beta, candidate=20
test and evaluation process.

In the unicode case, Jim discovered that find was several times slower=20
in 3.3 than 3.2 and claimed that that was a reason to not use 3.2. I ran =

the complete stringbency.py and discovered that find (and consequently=20
find and replace) are the only operations with such a slowdown. I also=20
discovered that another at least as common operation, encoding strings=20
that only contain ascii characters to ascii bytes for transmission, is=20
several times as fast in 3.3. So I reported that unless one is only=20
finding substrings in long strings, there is no reason to not upgrade to =

3.3.

--=20
Terry Jan Reedy