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
--
https://mail.python.org/mailman/listinfo/python-list
