On Wed, May 26, 2010 at 5:45 AM, M.-A. Lemburg <mal@egenix.com> wrote:
However, rather than using a distutils options to specify enable the agnostic mode, I would presume that extension writers simply write:
#define _Py_UNICODE_AGNOSTIC 1 #include "Python.h"
in their code and then add
[build_ext] unicode-agnostic=1
to their setup.cfg.
I think I was much too vague when I said "distutils option". I fear that I implied a command-line option, which is not at all what I intended. I was picturing that the module author would include something like the following in their setup.py:
Extension("foo", ["foo.c"], unicode_agnostic=True)
which would arrange to add _Py_UNICODE_AGNOSTIC to their define_macros. The module author would not (and should not) define the macro themselves at the top of a .c file. By enabling it in setup.py, we guarantee that it will be defined when compiling all of the module's .c files or not at all.
Rather than waiting for package managers to include support for this (I've been trying to get some awareness for this problem for years, without much success), it's probably better to just fix distutils to include a UCS2/UCS4 marker in the platform string.
In principle, I agree. I don't personally have enough familiarity with the innards of distutils to feel comfortable writing a patch that alters the platform string.
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>