This patch is (a first draft of) an attempt to make
Python properly use size_t where necessary. This work
is triggered by compilation on Win64 (where the
compiler warns about potential truncation errors a
lot). The rationale for the patch is that size_t might
be larger than int, in particular on 64-bit platforms,
and that the size of a memory chunk cannot reliably be
measured with an int.

It turns out that using size_t is not enough, since
values can sometimes also be negative. For these cases,
a "signed" size_t is used, which is called Py_ssize_t
and is a define for ssize_t if the compiler supports
the latter.

The guideline for converting int to size_t used in this
patch is this:
- if the variable is meant to store the number of
bytes, and is always guaranteed to be positive, and
could get arbitrarily large, use size_t
- if the value could be negative also, use ssize_t
- if the value is meant to store a number of "things",
but this directly translates into size_t (e.g. number
of pointers, number of characters), also use size_t/ssize_t
- if the value is in a range limited to 32-bit int
(e.g. the number of characters in a path name), convert
the size_t to int, after asserting that the value
really is in the range.

This version is work in progress, and needs review. I
hope to work on it during the sprints at PyConDC.

Logged In: YES 
user_id=21627

Second version of the patch attached (PyCon version). It turns out that 
changing everything from signed to unsigned breaks too many things, so 
this version of the patch uses Py_ssize_t in nearly all places.

Logged In: YES 
user_id=21627

This patch is now maintained in

http://svn.python.org/projects/python/branches/ssize_t/

Logged In: YES 
user_id=21627

And now it is part of the trunk.