flaming vs accuracy [was Re: Performance of int/long in Python 3]

[jmfauth]

On 28 mar, 07:12, Ethan Furman <et... at stoneleaf.us> wrote:
> On 03/27/2013 08:49 PM, rusi wrote:
>
> > In particular "You are a liar" is as bad as "You are an idiot"
> > The same statement can be made non-abusively thus: "... is not true
> > because ..."
>
> I don't agree.  With all the posts and micro benchmarks and other drivel that jmf has inflicted on us, I find it /very/
> hard to believe that he forgot -- which means he was deliberately lying.
>
> At some point we have to stop being gentle / polite / politically correct and call a shovel a shovel... er, spade.
>
> --
> ~Ethan~

-----------

The problem is elsewhere. Nobody understand the examples
I gave on this list, because nobody understand Unicode.
These examples are not random examples, they are well
thought.

If you were understanding the coding of the characters,
Unicode and what this flexible representation does, it
would not be a problem for you to create analog examples.

So, we are turning into circles.

This flexible representation succeeds to cumulate in one
shoot all the design mistakes it is possible to do, when
one wishes to implements Unicode.

Example of a good Unicode understanding.
If you wish 1) to preserve memory, 2) to cover the whole range
of Unicode, 3) to keep maximum performance while preserving the
good work Unicode.org as done (normalization, sorting), there
is only one solution: utf-8. For this you have to understand,
what is really a "unicode transformation format".

Why all the actors, active in the "text field", like MicroSoft,
Apple, Adobe, the unicode compliant TeX engines, the foundries,
the "organisation" in charge of the OpenType font specifications,
are able to handle all this stuff correctly (understanding +
implementation) and Python not?, I should say this is going
beyond my understanding.

Python has certainly and definitvely not "revolutionize"
Unicode.

jmf