Design-by-Committee

Alex Martelli aleaxit at yahoo.com
Fri May 4 13:10:58 CEST 2001


"Thomas Wouters" <thomas at xs4all.net> wrote in message
news:mailman.988969209.23679.python-list at python.org...
    [snip]
> Being one of the people who changed stuff since 1.5.2, I'm probably
biased,
> but I have to agree with this. I'm worried too, but not about the same
> things as AMK. For instance iterators, augmented assignment, import-as,
> distutils-setup, healing the type/class dichotomy all are good things to
me.

No disagreement...

> The only thing I really dislike in the changes since 1.5.2 is oddly enough
> unicode support, which AMK in a later posting declared the most important
> feature since 1.5.2 <wink>. I doubt I will ever need to use unicode, so
*to
> me*, it's a waste of resources.

You'll never need to handle XML files, for example?  Unicode is how
they're typically stored.  Never need for your apps to work in Osaka,
or to work both in Paris and Prague handling the same textfiles so
ISO-8859-1 does not suffice?  Never need to drive a COM server or
implement one?  And I think XPCOM uses Unicode like COM (not sure).

Sure, an unending series of ad-hoc character-set hackery _might_
"sort of work" in lieu of _one_ good Unicode support framework in
the language and core library -- let COM and Win32 interfacing
have its own little Unicode-handling setup, XPCOM its own, XML
reading its third one, ... but the total amount of resources you
can end up spending this way would seem to me to vastly exceed
those invested in putting Unicode handling in ONE place - just
think of what happens the first time somebody needs to have TWO
of those little hypothetical ad-hoc Unicode-handling-hacks that
work and interoperate within one single program!

Having _nothing BUT_ Unicode might be best if one designed a
language from scratch today -- Java doesn't seem to be overly
damaged by that simplifying design choice (yes, you may have
to worry about conversions when doing I/O or otherwise having
to communicate with other non-Unicode-aware programs).  But
in terms of _adding_ Unicode to a language originally designed
for single-byte character sets, the way it was handled in
Python seems exemplary to me... and the opportunity of doing
it at all, rather than trying to survive forever in a world
of more and more ad-hoc-Unicode-hackeries, beyond doubt.


Alex






More information about the Python-list mailing list