In article <4f384b6e$0$29986$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
> > I could hope for one and only one, but I know I'm just going to be > > disapointed. The last project I worked on used UTF-8 in most places, > > but also used some C and Java libraries which were only available for > > UTF-16. So it was transcoding hell all over the place. > > Um, surely the solution to that is to always call a simple wrapper > function to the UTF-16 code to handle the transcoding? What do the Design > Patterns people call it, a facade? No, an adapter. (I never remember the > names...) I am familiar with the concept. It was ICU. A very big library. Lots of calls. I don't remember the details, I'm sure we wrote wrappers. It was still a mess. > > Hopefully, we will eventually reach the point where storage is so cheap > > that nobody minds how inefficient UTF-32 is and we all just start using > > that. Life will be a lot simpler then. No more transcoding, a string > > will just as many bytes as it is characters, and everybody will be happy > > again. > > I think you mean 4 times as many bytes as characters. Unless you have 32 > bit bytes :) Yes, exactly. -- http://mail.python.org/mailman/listinfo/python-list
