unicode / osx / atsui

[Neil Hodgson]

james anderson:

> i'm trying to understand how best to approach unicode representations.
> i am told the pep-0261 is the standard for python.

   PEP 261 is the standard for the 4 byte wide implementation. It was
implemented after 2 byte Unicode which was documented after-the-fact in PEP
100.

> it was not clear what mechanism it entails for access to os-level text
> management facilities on the order of osx's "apple type services for
unicode
> imaging"[0].

   ATSUI is a text rendering library. Core Python doesn't include
text-rendering, leaving this up to GUI toolkits. Python does ship with Tk,
which has Unicode text support.

> i looked through the mac extensions, but did not discern anything
> relevant. can anyone point me to code in wide and narrow builds which uses
> such os-level facilities. i was given a reference which appeared to
concern
> windows' file names, but that, as is the case with direct stream codecs,
is
> primarly a static situation.

   Static as opposed to what? A fixed API that is explicitly wrapped versus
a dynamically wrapped system call convention as is done on Windows by
PythonCOM or ctypes?

> i would also be interested to hear if there have been any data collected
on
> preponderance of wide builds, and on the consequences in those
installations
> for storage and algorithm efficiency.

   Red Hat Linux 9.0 ships with a 4 byte wide build of Python and that is
quite widely distributed. On Windows, I would expect 4 byte to be very rare
as 2 byte matches the system conventions and the binary downloads available
from python.org are 2 byte builds.

   Neil