None of these warnings look critical (one affects the "search finger" optimization of pop(), one affects the result from __length_hint__ on set iterators, and the other the hash value of frozensets without any obviously bad consequences), but you might want to take a look at them anyway.

(for the record, a C "long" is 32-bit under 64-bit Windows, so a Py_ssize_t won't fit in it)

1>..\Objects\setobject.c(743) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'long', possible loss of data
1>..\Objects\setobject.c(772) : warning C4244: '*=' : conversion from 'Py_ssize_t' to 'long', possible loss of data
1>..\Objects\setobject.c(819) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data

For the length hint, it would be best to use PyLong_FromSize_t, as in dictobject.c. It would be sad if __length_hint__ would return a much-too-small value (or even a negative number).

For the search finger, dictobject has opted to make me_hash of type Py_ssize_t.

Antoine, thanks for posting these.

There is also a similar warning for deque iterators' __length_hint__ (line 1124 in _collectionsmodule.c).

This is now fixed in r84146 (py3k) and r84151 (3.1). I've made the "hash" field a Py_ssize_t, consistently with the dict implementation.

I'm not sure whether backporting it to 3.1 is a good idea. It's potentially an ABI change (although a minor one, as the field offsets remain the same, only the interpretation of the padding may change).

> I'm not sure whether backporting it to 3.1 is a good idea. It's
> potentially an ABI change (although a minor one, as the field offsets
> remain the same, only the interpretation of the padding may change).

Well, it is unlikely that anyone is accessing setentry structures
directly, given that no API function returns one, and the hash collision
resolution algorithm is not provided.