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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com