Ronald Oussoren wrote:
On 28 Aug, 2010, at 12:29, Martin v. Löwis wrote:
- wide-unicode: this is a tricky one. I'm tempted to say that the stable ABI should always use a Py_UNICODE that matches the platform's wchar_t. Alternative proposals are welcome.
Sizeof(wchar_t) is 4 on OSX, but the Apple frameworks use a 16-bit type to represent unicode codepoints (UniChar). Current builds on OSX use a 16-bit unicode type which makes it pretty cheap to convert strings from Python to a C array of UniChar.
I'm therefore -1 on switching to a wide unicode build on OSX.
-1 on always using wchar_t as well. Python's default is UCS2 and the stable ABI should not change that. 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(). BTW: Wasn't one of the main reasons for having versioned .so files the idea to be able to have UCS2 and UCS4 versions installed side-by-side ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 27 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2010-08-19: Released mxODBC 3.1.0 http://python.egenix.com/ 2010-09-15: DZUG Tagung, Dresden, Germany 18 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/