[I18n-sig] Re: Unicode debate

[Guido van Rossum]

> > > * import string fails due to the way _idtable is constructed
> > 
> > Hm, I don't see this -- string.py imports just fine.  There's no
> > _idtable in my copy of string.py?!?!
> 
> Ehm, I meant _idmap... I would guess that the reason
> your string.py imports fine is that the import still uses
> a cached PYC file for the import (this is why I updated the
> -U patch to modify the magic number for imports when the
> flag is set -- it ensures that when running in -U mode,
> only PYC files also having been compiled with -U are
> used and that when running without -U no such files
> are accepted; makes testing a little easier since it doesn't
> interfere with existing implementations).

Oops, you're right.

> > > * cPickle.loads() doesn't like Unicode as data storage
> > 
> > Hm, hard to fix.  Again, it really should use the buffer API, but it doesn't.
> 
> Note that this "bug" only occurrs when using strings as
> data storage... the test code should really be using
> a buffer object for this (or some other sort of binary
> data container).

Agreed.  (See my response to Just.)

> > > * keywords must be strings (f(1, 2, 3, **{'a':4, 'b':5}) doesn't work)
> > 
> > How hard would this be to fix?
> 
> Not sure... the keyword code is spread across many files.

I think it deserves to be fixed, but there's no great big hurry.

> > > Some of these could be fixed by putting a str() call around
> > > the '...' constants. Others need fixes in C code. Yet others
> > > would be better off if they used the buffer interfaces (basically
> > > all APIs which work on raw data like cPickle or rotor).
> > 
> > What I said. :-)
> 
> Should we go ahead with this for the 1.6 series or wait until 1.7 ?

Since the -U flag is in, I'd go ahead.

--Guido van Rossum (home page: http://www.python.org/~guido/)