[Python-3000] threading, part 2 --- + a bit of ctypes FFI worry

[Guido van Rossum]

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 <tim.peters at gmail.com> 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
> Python-3000 at python.org
> 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/)