Py 3.3, unicode / upper()
tjreedy at udel.edu
Thu Dec 20 23:12:20 CET 2012
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
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
More information about the Python-list