Flexible string representation, unicode, typography, ...

[Steven D'Aprano]

On Sun, 02 Sep 2012 11:58:08 -0700, wxjmfauth wrote:

> - Unfortunately, I got opposite and even much worst results on my win
> box, considering
> - libfrancais is one of my module and it does a little bit more than the
> std sorting tools.

How do we know that the problem isn't in your module?


> My rationale: very simple.
> 
> 1) I never heard about something better than sticking with one of the
> Unicode coding scheme. (genreral theory) 

Your ignorance is not a good reason for abandoning a powerful software 
technique.


2) I am not at all convinced by
> the "new" Py 3.3 algorithm. I'm not the only one guy, who noticed
> problems. 

That's nice.

Nobody has yet displayed genuine performance problems, only artificial 
and platform-dependent slowdowns that are insignificant in practice. If 
you can demonstrate genuine problems, people will be interested in fixing 
them.

Let me be frank: nobody gives a damn if, for some rare circumstances, 
some_string.replace(another_string) takes 0.3μs instead of 0.1μs. 
Overall, considering multiple platforms and dozens of different string 
operations, PEP 393 is a big win:

- many operations are faster
- a few operations are a LOT faster
- but a very few operations are sometimes slower
- many strings will use less memory
- sometimes a LOT less memory
- no more distinction between wide and narrow builds
- characters in the supplementary planes are now, for the first 
  time in Python, treated correctly by default

That's six wins versus one loss.


> Arguing, "it is fast enough", is not a correct answer.

It is *exactly* the correct answer.

Nobody is going to revert this just because your script now runs in 5.7ms 
instead of 5.2ms. Who cares?

If you are *seriously* interested in debugging why string code is slower 
for you, you can start by running the full suite of Python string 
benchmarks: see the stringbench benchmark in the Tools directory of 
source installations, or see here:

http://hg.python.org/cpython/file/8ff2f4634ed8/Tools/stringbench



-- 
Steven