Py 3.3, unicode / upper()

[Terry Reedy]

On 12/20/2012 2:19 PM, wxjmfauth at gmail.com wrote:

>
> If you are an "ascii" user, a FSR model has no sense. An
> "ascii" user will use, per definition, only "ascii characters".
>
> If you are a "non-ascii" user, the FSR model is also a non
> sense, because you are per definition a n"on-ascii" user of
> "non-ascii" character. Any optimisation for "ascii" user just
> become irrelevant.

This is a false dichotomy. Conclusions based on falsity are false.

> In one sense, to escape from this, you have to be at the same time
> a non "ascii" user and a non "non-ascii" user. Impossible.

This is wrong. Every Python user is an ascii user. All names in the 
stdlib are ascii-only. These names all become strings in code objects. 
All docstrings (with a couple of rare exceptions) are ascii-only. They 
also become strings. *Every Python user* benefits from the new system in 
3.3.

Some Python users are also non-ascii user. This include many English 
speakers, as many English texts include non-ascii characters. (Just for 
starters, the copyright and trademark symbols are not in the ascii set.)

> Contrary to what has been said, the bad cases I presented here are
> not corner cases. There is practically and systematically a regression
> in Py33 compared to Py32.

I posted evidence otherwise. Jim never responded to those posts. Instead 
he repeats the falsehood refuted by evidence.

> That's very easy to test.

Yes. Run stringbench.py on the OS/machine on 3.2 and 3.3 as I did.

-- 
Terry Jan Reedy