Fredrik Lundh wrote: > M.-A. Lemburg wrote: > > >>>Yes. Whatever MAL and Barry thinks, Python's current model is 8+8=8, >>>U+U=U, and 8+U=U for ascii U. That's an advantage, not a bug. >> >>Indeed, but I don't see how that's different from what the PEP >>is saying. > > > the current implementation is > > T(8) % 8 = U. > > which violates the 8+8=8 rule. T is a sub-class of Unicode, so you have: U % 8 = U which is just fine. >>>And when that time comes, storing everything as 32-bit characters is not the >>>right answer either. >> >>I'll leave that for the libc designers to decide :-) >> >>If you look at performance, there's not much difference between >>8-bit strings and Unicode, so the only argument against using >>Unicode for storing text data is memory usage. > > I used to make that argument, but these days, I no longer think that you can > talk about performance without taking memory usage into account. You always have to take both into account. I was just saying that 8-bit strings don't buy you much in terms of performance over Unicode these days, so the only argument against using Unicode would be doubled memory usage. Of course, this is a rather mild argument given the problems you face when trying to localize applications - which I see as the main use case for templates. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 05 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4