On 20/04/2013 19:02, Benjamin Kaplan wrote:
On Sat, Apr 20, 2013 at 10:22 AM, Ned Batchelder <n...@nedbatchelder.com> wrote:
On 4/20/2013 1:12 PM, jmfauth wrote:
In a previous post,
http://groups.google.com/group/comp.lang.python/browse_thread/thread/6aec70817705c226#
,
Chris “Kwpolska” Warrick wrote:
“Is Unicode support so hard, especially in the 21st century?”
--
Unicode is not really complicate and it works very well (more
than two decades of development if you take into account
iso-14****).
But, - I can say, "as usual" - people prefer to spend their
time to make a "better Unicode than Unicode" and it usually
fails. Python does not escape to this rule.
-----
I'm "busy" with TeX (unicode engine variant), fonts and typography.
This gives me plenty of ideas to test the "flexible string
representation" (FSR). I should recognize this FSR is failing
particulary very well...
I can almost say, a delight.
jmf
Unicode lover
I'm totally confused about what you are saying. What does "make a better
Unicode than Unicode" mean? Are you saying that Python is guilty of this?
In what way? Can you provide specifics? Or are you saying that you like
how Python has implemented it? "FSR is failing ... a delight"? I don't
know what you mean.
--Ned.
Don't bother trying to figure this out. jmfauth has been hijacking
every thread that mentions Unicode to complain about the flexible
string representation introduced in Python 3.3. Apparently, having
proper Unicode semantics (indexing is based on characters, not code
points) at the expense of performance when calling .replace on the
only non-ASCII or BMP character in the string is a horrible bug.
He can't complain about performance for the .replace issue any more as
it's been fixed http://bugs.python.org/issue16061
Sadly he'll almost certainly have more edge cases up his sleeve while
continuing to ignore minor issues like memory saving and correctness.
--
If you're using GoogleCrap™ please read this
http://wiki.python.org/moin/GoogleGroupsPython.
Mark Lawrence
--
http://mail.python.org/mailman/listinfo/python-list
