Let ssize_t be a native type.

[robertwb]

We support size_t, we should support ssize_t as well.

[haoyu]

Patch to add ssize_t, includes a test case

[scoder]

I didn't test the patch, but it looks good at a quick glance.

[robertwb]

It may be worth creating the PyObject? module name at module load time (do we do that already), and simply re-using that, rather than re-creating it for every function.

[robertwb]

Oops, I was talking about #422

[dagss]

I'm worried about the 1 << 31 etc. in the testcases -- will the testcases only work on 32 bit machines?

You can check "sizeof(ssize_t)" and generate the docstring conditionally on that.

[dalcinl]

Pushed:  http://hg.cython.org/cython-devel/rev/1a9bfb4ff18a Tested: Linux32/64 and Windows32 (MSVC and MinGW)

Comments: 'ssize_t' is not a C99 standard type. If available, core Python(>2.4) defines Py_ssize_t to ssize_t. If ssize_t is not available, then any Cython code using ssize_t will fail at C compile time. I do not think we should #define or typedef ssize_t if it is missing, but raise your voice if you do not agree. For Py>=2.5, detecting a missing ssize_t is trivial (macro available pyconfig.h) and then we could conditionally "#define ssize_t Py_ssize_t" (or ptrdiff_t).

For older Python(<2.5), the to_py/from_py conversions will end-up being performed with the PyInt?_{As|From}Long() functions, so things will be fine for Linux{32|64}, Windows32, and not sure what happens on OS X 32/64.

PS: From the list of mayor platforms, Win64 is the only one where things are broken for Py<2.5 . Provided that full 64bits support was introduced in Py2.5, I do not actually care too much. If anyone complains about this, I'll politely ask her to donate a Win64 license ;-) in order to support Cython development.

[dalcinl]

In Cython-Dev was agreed that 'ssize_t' in Cython should mean 'Py_ssize_t' in C.

 http://hg.cython.org/cython-devel/rev/bc1e09f2fef7