Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Chris Angelico <rosuav@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Pyhon 2.x or 3.x, which is faster?
Date: Fri, 11 Mar 2016 16:36:06 +1100
Lines: 40
Message-ID: <mailman.171.1457674574.15725.python-list@python.org>
References: <mailman.238.1457265255.20602.python-list@python.org> <mailman.7.1457395587.15725.python-list@python.org> <nbl81v$hii$1@dont-email.me> <mailman.16.1457399576.15725.python-list@python.org> <nblapf$ofi$1@dont-email.me> <mailman.28.1457405184.15725.python-list@python.org> <nbmbnp$hsi$1@dont-email.me> <mailman.45.1457453433.15725.python-list@python.org> <nbn871$8np$1@dont-email.me> <56df6761$0$1588$c3e8da3$5496439d@news.astraweb.com> <mailman.72.1457512871.15725.python-list@python.org> <nbp36e$560$1@dont-email.me> <mailman.96.1457558042.15725.python-list@python.org> <nbqaja$5g5$1@dont-email.me> <mailman.98.1457566570.15725.python-list@python.org> <nbqgmi$mha$1@dont-email.me> <mailman.108.1457595070.15725.python-list@python.org> <nbrms1$26p$1@dont-email.me> <mailman.123.1457612163.15725.python-list@python.org> <nbrq7b$eeu$1@dont-email.me> <mailman.127.1457615320.15725.python-list@python.org> <nbrvpj$5lm$1@dont-email.me> <mailman.153.1457640433.15725.python-list@python.org> <56e25245$0$1606$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <56e25245$0$1606$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:104584

On Fri, Mar 11, 2016 at 4:06 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> That may be true, but that doesn't mean that there isn't still room in the
> world for dumb, just-barely Unicode capable clients. And frankly I would
> rather partial Unicode support than buggy Unicode support: I have a text
> editor which would be my preferred editor of choice except it has an
> annoying bug where it will (seemingly at random) switch to Right-To-Left
> mode for no reason, and then be impossible to switch back. Since I have
> *no* use for RTL, I would rather an editor that doesn't support that than
> one that supports it buggily.

What would this hypothetical "doesn't support RTL" editor do if given
Arabic or Hebrew text? I'd rather it support it buggily (and
acknowledge that those are bugs) than try to render the characters in
a completely wrong way. Also, you trimmed off the last bit of my
original post, which probably should have had more emphasis:

[I said:]
> You can't ignore this, although you might be able to leave
> full support for later - but it's a bug until you do.

You don't necessarily have to have perfect support for everything
straight away; what you DO need is a mental attitude of "perfection
means full Unicode support, and anything else is a bug". Bugs hang
around in programs for a long time, but removing them is always an
improvement. So, for instance, you might not properly support RTL
text, but if a patch comes along that fixes RTL text, you would not
dismiss it as "we've done it this way for years, so it's fine" - it's
a bug that can be fixed. Same goes for correct handling of combining
characters (the cursor shouldn't be able to go between a base char and
a combining char, for instance); if you get something wrong, it's a
bug, same as any other bug.

There most definitely is room in the world for "just-barely Unicode
capable" programs, just as there's room in the world for programs that
segfault when you feed them certain types of invalid data. The program
can still be useful even though it has bugs in it. Nobody would deny
that segfaulting on invalid data is a flaw; and imperfect Unicode
support should be treated the same way.

ChrisA