On 18/08/2012 21:22, wxjmfa...@gmail.com wrote:
Le samedi 18 août 2012 20:40:23 UTC+2, rusi a écrit :
On Aug 18, 10:59 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
On Sat, 18 Aug 2012 08:07:05 -0700, wxjmfauth wrote:
Is there any reason why non ascii users are somehow penalized compared
to ascii users?
Of course there is a reason.
If you want to represent 1114111 different characters in a string, as
Unicode supports, you can't use a single byte per character, or even two
bytes. That is a fact of basic mathematics. Supporting 1114111 characters
must be more expensive than supporting 128 of them.
But why should you carry the cost of 4-bytes per character just because
someday you *might* need a non-BMP character?
I am reminded of:
http://answers.microsoft.com/thread/720108ee-0a9c-4090-b62d-bbd5cb1a7605
Original above does not open for me but here's a copy that does:
http://onceuponatimeinindia.blogspot.in/2009/07/hard-drive-weight-increasing.html
I thing it's time to leave the discussion and to go to bed.
In plain English, duck out cos I'm losing.
You can take the problem the way you wish, Python 3.3 is "slower"
than Python 3.2.
I'll ask for the second time. Provide proof that is acceptable to
everybody and not just yourself.
If you see the present status as an optimisation, I'm condidering
this as a regression.
Considering does not equate to proof. Where are the figures which back
up your claim?
I'm pretty sure a pure ucs-4/utf-32 can only be, by nature,
the correct solution.
I look forward to seeing your patch on the bug tracker. If and only if
you can find something that needs patching, which from the course of
this thread I think is highly unlikely.
To be extreme, tools using pure utf-16 or utf-32 are, at least,
considering all the citizen on this planet in the same way.
jmf
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
