On 1/5/14 9:23 AM, wxjmfa...@gmail.com wrote:
Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a écrit :
On 1/4/2014 2:10 PM, wxjmfa...@gmail.com wrote:
I do not mind to be considered as an idiot, but
I'm definitively not blind.
And I could add, I *never* saw once one soul, who is
explaining what I'm doing wrong in the gazillion
of examples I gave on this list.
If this is true, it is because you have ignored and not read my
numerous, relatively polite posts. To repeat very briefly:
1. Cherry picking (presenting the most extreme case as representative).
2. Calling space saving a problem (repeatedly).
3. Ignoring bug fixes.
4. Repetition (of the 'gazillion example' without new content).
Have you ever acknowledged, let alone thank people for, the fix for the
one bad regression you did find. The FSR is still a work in progress.
Just today, Serhiy pushed a patch speeding up the UTF-32 encoder, after
previously speeding up the UTF-32 decoder.
--
My examples are ONLY ILLUSTRATING, this FSR
is wrong by design, can be on the side of
memory, performance, linguistic or even
typography.
JMF: this has been pointed out to you time and again: the flexible
string representation is not wrong. To show that it is wrong, you would
have to demonstrate some semantic of Unicode that is violated. You have
never done this. You've picked pathological cases and shown
micro-timing output, and memory usage. The Unicode standard doesn't
promise anything about timing or memory use.
The FSR makes a trade-off of time and space. Everyone but you considers
it a good trade-off. I don't think you are showing real use cases, but
if they are, I'm sorry that your use-case suffers. That doesn't make
the FSR wrong. The most accurate statement is that you don't like the
FSR. That's fine, you're entitled to your opinion.
You say the FSR is wrong linguistically. This can't be true, since an
FSR Unicode string is indistinguishable from an internally-UTF-32
Unicode string, and no, memory use or timings are irrelevant when
discussing the linguistic performance of a Unicode string.
You've also said that the internal representation of the FSR is
incorrect because of encodings somehow. Encodings have nothing to do
with the internal representation of a Unicode string, they are for
interchanging data. You seem to know a lot about Unicode, but when you
make this fundamental mistake, you call all of your expertise into question.
To re-iterate what you are doing wrong:
1) You continue to claim things that are not true, and that you have
never substantiated.
2) You paste code samples without accompanying text that explain what
you are trying to demonstrate.
3) You ignore refutations that disprove your points.
These are all the behaviors of a troll. Please stop.
If you want to discuss the details of Unicode implementations, I'd
welcome an offlist discussion, but only if you will approach it honestly
enough to leave open the possibility that you are wrong. I know I would
be glad to learn details of Unicode that I have missed, but so far you
haven't provided any.
--Ned.
I will not refrain you to waste your time
in adjusting bytes, if the problem is not
on that side.
jmf
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
