[I18n-sig] Re: Unicode debate
Guido van Rossum
guido@python.org
Mon, 01 May 2000 16:44:10 -0400
> > > * 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/)