Unicode 7

[Terry Reedy]

On 5/1/2014 10:29 PM, Rustom Mody wrote:

> Here is an instance of someone who would like a certain optimization to be
> dis-able-able
>
> https://mail.python.org/pipermail/python-list/2014-February/667169.html
>
> To the best of my knowledge its nothing to do with unicode or with jmf.

Right. Ned has an actual technical reason to complain, even though the 
developers do not consider it strong enough to act.

> Why if optimizations are always desirable do C compilers have:
> -O0 O1 O2 O3 and zillions of more specific flags?

One reason is that many optimizations sometimes introduce bugs, or to 
put it another way, they are based on assumptions that are not true for 
all code. For instance, some people have suggested that CPython should 
have an optional optimization based on the assumption that builtin names 
are never rebound. That is true for perhaps many code files, but 
definitely not all. Guido does not seem to like such conditional 
optimizations.

I can think of three reasons for not adding to the numerous options 
CPython already has.
1. We do not have the developers resources to handle the added 
complications of multiple optimization options.
2. Zillions of options and flags confuse users. As it is, most options 
are seldom used.
3. Optimization options are easily misused, possibly leading to silently 
buggy results, or mysterious failures. For instance, people sometimes 
rebind builtins without realizing what they have done, such as using 
'id' as a parameter name. Being in the habit of routinely using the 
'assume no rebinding option' would lead to problems.

I am rather sure that the string (unicode) test suite was reviewed and 
the performance of 3.2 wide builds recorded before the new 
implementation was committed.

The tracker currently has 37 behavior (bug) issues marked for the 
unicode component. In a quick review, I do not see that any have 
anything to do with using standard UTF-32 versus adaptive UTF-32. 
Indeed, I believe a majority of the 37 were filed before 3.3 or are 2.7 
specific. Problems with FSR itself have been fixed as discovered.

> JFTR I have no issue with FSR.  What we have to hand to jmf - willingly
> or otherwise - is that many more people have heard of FSR thanks to him. [I am one of them]

Somewhat ironically, I suppose your are right.

> I dont even know whether jmf has a real
> technical (as he calls it 'mathematical') issue or its entirely political:

I would call his view personal or philosophical. I only object to 
endless repetition and the deception of claiming that personal views are 
mathematical facts.

-- 
Terry Jan Reedy