flaming vs accuracy [was Re: Performance of int/long in Python 3]
wxjmfauth at gmail.com
Thu Mar 28 21:26:57 CET 2013
On 28 mar, 18:55, Chris Angelico <ros... at gmail.com> wrote:
> On Fri, Mar 29, 2013 at 4:48 AM, jmfauth <wxjmfa... at gmail.com> wrote:
> > If Python had imlemented Unicode correctly, there would
> > be no difference in using an "a", "é", "€" or any character,
> > what the narrow builds did.
> I'm not following your grammar perfectly here, but if Python were
> implementing Unicode correctly, there would be no difference between
> any of those characters, which is the way a *wide* build works. With a
> narrow build, there is a difference between BMP and non-BMP
The wide build (I never used) is in my mind as correct as
the narrow build. It "just" covers a different range in unicode
(the whole range).
Claiming that the narrow build is buggy, because it does not
cover the whole unicode is not correct.
Unicode does not stipulate, one has to cover the whole range.
Unicode expects that every character in a range behaves the same
way. This is clearly not realized with the flexible string
representation. An user should not be somehow penalized
simply because it not an ascii user.
If you take the fonts in consideration (btw a problem nobody
is speaking about) and you ensure your application, toolkit, ...
is MES-X or WGL4 compliant, your are also deliberately (and
correctly) working with a restriced unicode range.
More information about the Python-list