cached encoding (Re: [Python-Dev] Internationalization Toolkit)

[M.-A. Lemburg]

Fredrik Lundh wrote:
> 
> Guido van Rossum <guido@CNRI.Reston.VA.US> wrote:
> > One specific question: in you discussion of typed strings, I'm not
> > sure why you couldn't convert everything to Unicode and be done with
> > it.  I have a feeling that the answer is somewhere in your case study
> > -- maybe you can elaborate?
> 
> Marc-Andre writes:
> 
>     Unicode objects should have a pointer to a cached (read-only) char
>     buffer <defencbuf> holding the object's value using the current
>     <default encoding>.  This is needed for performance and internal
>     parsing (see below) reasons. The buffer is filled when the first
>     conversion request to the <default encoding> is issued on the object.
> 
> keeping track of an external encoding is better left
> for the application programmers -- I'm pretty sure that
> different application builders will want to handle this
> in radically different ways, depending on their environ-
> ment, underlying user interface toolkit, etc.

It's not that hard to implement. All you have to do is check
whether the current encoding in <defencbuf> still is the same
as the threads view of <default encoding>. The <defencbuf>
buffer is needed to implement "s" et al. argument parsing
anyways.
 
> besides, this is how Tcl would have done it.  Python's
> not Tcl, and I think you need *very* good arguments
> for moving in that direction.
> 
> </F>
> 
> _______________________________________________
> Python-Dev maillist  -  Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    51 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/