[Pyrex] Updated Python 2.5 patch

[Stefan Behnel]

Sorry, I was partly mistaken in my last post.

Stefan Behnel wrote:
> I removed the support for "Py_ssize_t" as standard
> C type from the parser, the difference to the previous patch is the following:
> 
> ----------------------------
> Index: Pyrex/Compiler/Parsing.py
> ===================================================================
> --- Pyrex/Compiler/Parsing.py   (Revision 136)
> +++ Pyrex/Compiler/Parsing.py   (Arbeitskopie)
> @@ -1257,7 +1257,7 @@
>  #      "void", "signed", "unsigned"
>  #)
> 
> -basic_c_type_names = ("void", "char", "int", "float", "double", "Py_ssize_t")
> +basic_c_type_names = ("void", "char", "int", "float", "double")
> 
>  sign_and_longness_words = ("short", "long", "signed", "unsigned")
> 
> ----------------------------

Ok, this doesn't work. It compiled nicely, but when I checked the generated C
source, the Py_ssize_t's were happily replaced by 'int'. So, the Pyrex parser
apparently needs to know about this type. Back to my previous patch then (mail
as of 20060502-1417).

However, the following is still true *if* you want things to compile with
older Pyrex versions:

> You must import Py_ssize_t from "Python.h" (just as PyObject and the like):
> 
> cdef extern from "Python.h":
>     ctypedef int Py_ssize_t
> 
> Also, you need this somewhere in an imported header file:
> 
> ------------------------------------
> /* Py_ssize_t support was added in Python 2.5 and Pyrex 0.9.X */
> #if PY_VERSION_HEX < 0x02050000
> #ifndef PY_SSIZE_T_MAX
>   typedef int Py_ssize_t;
>   #define PY_SSIZE_T_MAX INT_MAX
>   #define PY_SSIZE_T_MIN INT_MIN
>   #define PyInt_FromSsize_t(z) PyInt_FromLong(z)
>   #define PyInt_AsSsize_t(o)   PyInt_AsLong(o)
> #endif
> #endif
> ------------------------------------
> 
> The "#ifndef" is needed as the patched Pyrex already defines this section.
> 
> I hope this will be integrated rather soon so that people can start preparing
> their Pyrex code for Python 2.5.

I still hope so. However, the double declaration now looks a little clumsy
(although not too bad) to me, especially because it is overridden internally
by the patched Pyrex version. I'm not sure how to make this look better, as we
should try to keep new code working with older Pyrex versions. The solution
above works nicely with Pyrex 0.9.4.1 under Python 2.4.

Greg, any ideas?

Stefan