Nicholas Bastin wrote: > On May 4, 2005, at 6:03 PM, Martin v. Löwis wrote: > > >>Nicholas Bastin wrote: >> >>>"This type represents the storage type which is used by Python >>>internally as the basis for holding Unicode ordinals. Extension >>>module >>>developers should make no assumptions about the size of this type on >>>any given platform." >> >>But people want to know "Is Python's Unicode 16-bit or 32-bit?" >>So the documentation should explicitly say "it depends". > > > The important piece of information is that it is not guaranteed to be a > particular one of those sizes. Once you can't guarantee the size, no > one really cares what size it is. The documentation should discourage > developers from attempting to manipulate Py_UNICODE directly, which, > other than trivia, is the only reason why someone would care what size > the internal representation is.
I don't see why you shouldn't use Py_UNICODE buffer directly. After all, the reason why we have that typedef is to make it possible to program against an abstract type - regardless of its size on the given platform. In that respect it is similar to wchar_t (and all the other *_t typedefs in C). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 06 2005) >>> 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 ! :::: _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
