-1 on always using wchar_t as well. Python's default is UCS2 and the stable ABI should not change that.
It's not really Python's default. It is what configure.in does by default. Python's default, on Linux, is UCS-4.
I also think that this information is not relevant for the stable ABI: Extensions that want to stick to the stable ABI should really not have to know whether Py_UNICODE maps to wchar_t or not. If they want to interface to a local whcar_t type they can use the conversion APIs we have for that in the Unicode API: PyUnicode_FromWideChar() and PyUnicode_AsWideChar().
Ok. I'm fine with excluding Py_UNICODE from the stable ABI. However, I think in the long run, I guess more support for wchar_t will then be needed in the API, e.g. more convenient argument parsing. Regards, Martin