On 9/29/05, Robey Pointer <robey at lag.net> wrote:
Yesterday I ran into a bug in the C API docs. The top of this page:
http://docs.python.org/api/unicodeObjects.html
says:
Py_UNICODE This type represents a 16-bit unsigned storage type which is used by Python internally as basis for holding Unicode ordinals. On platforms where wchar_t is available and also has 16-bits, Py_UNICODE is a typedef alias for wchar_t to enhance native platform compatibility. On all other platforms, Py_UNICODE is a typedef alias for unsigned short.
Steven Bethard wrote:
I believe this is the same issue that was brought up in May[1]. My impression was that people could not agree on a documentation patch.
[1] http://www.python.org/dev/summary/2005-05-01_2005-05-15.html
I thought the problem was disagreement over how the system *should* pick an underlying type to alias. Given the current policy, are there objections to a patch that at least steers people away from assuming they can use the underlying type directly? ======== Py_UNICODE Python uses this type to store Unicode ordinals. It is typically a typedef alias, but the underlying type -- and the size of that type -- varies across different systems. ======== -jJ
Jim Jewett wrote:
======== Py_UNICODE Python uses this type to store Unicode ordinals. It is typically a typedef alias, but the underlying type -- and the size of that type -- varies across different systems. ========
I think I objected to such a formulation, requesting that the precise procedure is documented for chosing the alias. I then went on saying what the precise procedure is, and then an argument about that procedure arose. I still believe that the precise procedure should be documented (in addition to saying that its outcome may vary across installations). Regards, Martin
participants (2)
-
"Martin v. Löwis" -
Jim Jewett