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

[Oscar Benjamin]

On 28 March 2013 09:03, jmfauth <wxjmfauth at gmail.com> wrote:
>
> 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.

There are many people here and among the Python devs who understand
unicode. Similarly they have understood the examples that you have
given. It has been accepted that there are a handful of cases where
performance has been reduced as a result of the change. There are also
many cases where the performance has improved. It is certainly not
clear that there is an *overall* performance reduction for people
using non latin-1 characters as you have often suggested.

The reason your initial posts received a poor reception is that they
were accompanied with pointless rants and arrogant claims that no one
understood the problem. Had you simply reported the timing differences
without the rants then I imagine that you would have received a
response like "Okay, there might be a few regressions. Can you open an
issue on the tracker please?".

Since then you have been relentlessly hijacking unrelated threads and
this is clearly just trolling.

>
> 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.

This is clearly untrue.The most significant design mistakes are the
ones that lead to incorrect handling of unicode characters. This new
implementation in Python 3.3 has been designed in a way that makes it
possible to handle all unicode characters correctly.

>
> 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".

Again you pretend that others here don't understand. Most people here
are well aware of utf-8 is. Your suggestion that "maximum performance"
would be achieved if Python use utf-8 internally ignores the fact that
it would have many negative performance implications for slicing and
indexing and so on.

>
> 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.

Perhaps not, but it does now correctly handle all unicode characters
(unlike many other languages and pieces of software).


Oscar