[I18n-sig] Re: Python Character Model

Paul Prescod paulp@ActiveState.com
Thu, 08 Feb 2001 12:11:12 -0800


"Martin v. Loewis" wrote:
> 
> ...
> 
> Move-away-from, perhaps. Outright force moving by breaking people's
> code, no.

Guido has been very clear that breaking incorrect code is not
necessarily a problem. Remember the two-arg socket issue?

Anyhow, I was against the two-arg socket change and I would be against a
string/unicode unification *today*. But I strongly believe that we
should announce that that is the direction we are going so that people
can fix their code to conform with the coming world order. We have a
deprecation/warning mechanism precisely so that we can change the
language gradually -- even in backwards-incompatible ways.

> > In another message you admitted that the codec mechanism is somewhat
> > user unfriendly...so I hope we agree that we need something better.
> 
> No, I admitted that it is inconsequential if read as English. It is no
> more or less friendly than a module that's called, say, file, so you'd
> use file.open. In either case, the user will have to learn what to use.

I'll repeat the point that when you make the recommended way to do
things harder than the non-recommended (in this case implicit) way,
people will be slow to move if they ever move at all. Usability!

> Many Python users won't guess the right meaning into codec, just as
> many people won't guess what "modem" stands for - yet they are fully
> capable of using it (despite its demodulating nature :).

You seem to agree above that file is a better name so I'm not sure why
we're still talking about "codec"! The only question is whether it
should be file.open, fileopen or reusing our existing open. Do you have
any problems with reusing open with a quasi-mandatory (HIGHLY
RECOMMENDED!) encoding argument?

 Paul Prescod