Hi Martin,

On Fri, Dec 30, 2005 at 11:26:44AM +0100, "Martin v. L?wis" wrote:
>  > Hum.  It would be much cleaner to introduce a new format character to
>  > replace '#' and deprecate '#'...
>  
>  That would certainly be clearer. What character would you suggest?
>  
>  I see two drawbacks with that approach:
>  1. writing backwards-compatible modules will become harder.
>     Users have to put ifdefs around the ParseTuple calls (or atleast
>     around the format strings)

Ok, I see your point.

In theory we could reuse a macro-based trick in C extensions:

#include <Python.h> 
#ifndef Py_SIZE_CHR
typedef int Py_Ssize_t;
#define Py_SIZE_CHR "#"
#endif

And then we can replace -- say -- the format string "is#s#" with

    "is" Py_SIZE_CHR "s" Py_SIZE_CHR

But it's rather cumbersome.

An equally strange alternative would be to start C modules like this:

#define Py_Ssize_t int  /* compatibility with Python <= 2.4 */
#include <Python.h> 

This would do the right thing for <= 2.4, using ints everywhere; and the
Python.h version 2.5 would detect the #define and assume it's a
2.5-compatible module, so it would override the #define with the real
thing *and* turn on the ssize_t interpretation of the '#' format
character.

Not that I think that this is a good idea.  Just an idea.

I still don't like the idea of a magic #define that changes the behavior
of '#include <Python.h> ', but I admit I don't find any better solution.
I suppose I'll just blame C.


A bientot,

Armin
_______________________________________________
Python-Dev mailing list
Python-Dev@[...].org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.c
om