Design-by-Committee

[David LeBlanc]

In article <9cu2o201ih6 at news2.newsguy.com>, aleaxit at yahoo.com says...
> "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
> 
> 
D'accord! 

The number of opportunities for using ASCII are dwindling fast, although, 
as the next poster points out there are and will be niches where ascii 
_might_ hold out. Probably not though, given the move towards 
globalization and the exchange of scientific data etc. between different 
countries.

I think ignoring Unicode is about as sane as those who stuck doggedly to 
procedural language (i.e. Fortran, C) in opposition to Object 
Orientation's entering the mainstream in the mid-80's.

XML is, imho, the most important thing that's happened to data since the 
advent of computers. We spent roughly 5 decades polishing and structuring 
computer languages whilst leaving data pretty much an ad-hoc affair. Now, 
with XML, we can create, share and manipulate fine grained data 
structures across architectures and programming languages. It might not 
be the sine non qua (sp?) of data structuring technologies, but it's head 
and shoulders above all other contenders i'm aware of, including it's 
parent SGML.

Aside from all that, Unicode just isn't all that evil - UTF-8 is ascii's 
near cousin. I personally would like to see Python evolve _soon_ towards 
becoming unicode-centric with ascii the secondary encoding.

Dave LeBlanc