[ python-Feature Requests-1485576 ] Backwards compatibility support for Py_ssize_t

[SourceForge.net]

Feature Requests item #1485576, was opened at 2006-05-10 13:28
Message generated for change (Comment added) made by hinsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backwards compatibility support for Py_ssize_t

Initial Comment:
PEP353 recommends to add the following code snippet to extension 
modules to ensure compatibility with pre-2.5 interpreters:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif

This is insufficient, because type definitions that use Py_ssize_t must 
also be added. Here is what works for me, though they may be more 
definitions to be included:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
typedef Py_ssize_t (*lenfunc)(PyObject *);
typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, 
Py_ssize_t);
typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, 
PyObject *);
typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **);
#endif

However, the main problem is elsewhere. Extension modules may well 
need to use Py_ssize_t in their own data types, and may furthermore 
with to make these data types available to yet other extension 
modules. In practice, this requires the inclusion of a code block such 
as the one shown above inside header files. However, this requires a 
mechanism for avoiding redefinitions, which at the moment does not 
seem to exist. My request is to add such a mechanism to Python 2.5 
and recommend its consistent use in an update of PEP353.

Concretely, I propose that Python 2.5 should define a macro 
PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion 
of the code snippet

#ifndef PY_HAS_PY_SSIZE_T
#define PY_HAS_PY_SSIZE_T
typedef int Py_ssize_t;

/* add all the other definitions here */

#endif

that contains an exhaustive set of definitions that depend on 
Py_ssize_t.


----------------------------------------------------------------------

>Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:18

Message:
Logged In: YES 
user_id=11850

I have read that section, but I am not yet convinced that I can avoid those 
casts with all common C compilers - and since I cannot try them all, I'd rather 
play safe and keep the casts. If they were never necessary, why were those 
typedefs introduced at all?

Anyway, it is not the additional typedefs that are the essence of my feature 
request. The main issue is that if multiple header files introduce Py_ssize_t, 
the compiler will stop with an error message.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2006-05-12 14:06

Message:
Logged In: YES 
user_id=21627

Please re-read the section immediately following the #ifdef
code in PEP 353. It explains how you should avoid these
other typedefs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470