Perhaps this thread can be moved back to python-dev? I'm not sure how relevant a discussion of the ambiguities in ctypes' docs are for Py3k.
On 8/14/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Tim Peters] > >> ... > >> When the ctypes docs talk about passing and returning integers, they > >> never explain what "integers" /means/, but it seems the docs > >> implicitly have a 32-bit-only view of the world here. In reality > >> "integer" seems to mean the native C `int` type. > > [Thomas Heller] > > 'ctypes.c_int' and 'ctypes.c_long' correspond to the C 'int' and 'long' > > types. > > Sure, that's clear. It's where the docs talk about (the unqualified) > "integers", and the quotes there aren't just to scare you ;-). Like > in: > > http://starship.python.net/crew/theller/ctypes/tutorial.html > > near the end of section "Calling functions": > > Python integers, strings and unicode strings are the only objects that can > directly be used as parameters in these function calls. > > What does the word "integers" /mean/ there? > > > If you think that the docs could be clearer, please suggest changes. > > I can't, because I don't know what was intended. Python integers come > in two flavors, `int` and `long`, so I assumed at first that the > "Python integers" in the above probably meant "a Python (short) int" > (which is a C `long`). But writing the thread test using that > assumption failed on some 64-bit buildbots. After staring at the > specific ways it failed, my next guess was that by "Python integers" > the docs don't really mean Python integers at all, but C's `int`. > That's what convinced me to /try/ wrapping the thread id in > ctypes.c_long(), and the test problems went away then, so I did too > :-) > > I searched all the docs for the word "integers" and never found out > what was intended. So you could search the docs for the same thing. > Like, still in the tutorial, at the start of section "Return types": > > By default functions are assumed to return integers. > > Or in the reference docs: > > Note that all these functions are assumed to return integers, > which is of course > not always the truth, so you have to assign the correct restype > attribute to use > these functions. > > and the description of memmove(): > > memmove(dst, src, count) > > Same as the standard C memmove library function: copies count bytes from > src to dst. dst and src must be integers or ... > > Python has at least three meanings for the word "integer" (short, > long, & "either"), and C has at least 10 (signed & unsigned char, > short, int, long, & long long), so the unqualifed "integer" is highly > ambiguous. While in many contexts that doesn't much matter, in ctypes > it does. > _______________________________________________ > Python-3000 mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
