Python API version & optional features
I guess one could argue that extension writers should check for narrow/wide builds in their extensions before using Unicode.
Since the number of Unicode extension writers is much smaller than the number of users, I think that this apporach would be reasonable, provided that we document the problem clearly in the NEWS file.
OK. I approve.
I'm not sure I can follow. What did you approve? That extension writers should check whether their Unicode build matches the one they get at run-time? How are they going to do that? Regards, Martin
I guess one could argue that extension writers should check for narrow/wide builds in their extensions before using Unicode.
Since the number of Unicode extension writers is much smaller than the number of users, I think that this apporach would be reasonable, provided that we document the problem clearly in the NEWS file.
OK. I approve.
I'm not sure I can follow. What did you approve? That extension writers should check whether their Unicode build matches the one they get at run-time? How are they going to do that?
With an explicit call. They know their compile-time unicode width, they can pass that to a function defined in the main Python/C API which asserts that the argument is the same as *its* compile-time unicode width. --Guido van Rossum (home page: http://www.python.org/~guido/)
"Martin v. Loewis" wrote:
I guess one could argue that extension writers should check for narrow/wide builds in their extensions before using Unicode.
Since the number of Unicode extension writers is much smaller than the number of users, I think that this apporach would be reasonable, provided that we document the problem clearly in the NEWS file.
OK. I approve.
I'm not sure I can follow. What did you approve?
To use macros in unicodeobject.h which then map all interface names to either PyUnicodeUC2_* or PyUnicodeUCS4_*. The linker will then report the mismatch in interfaces.
That extension writers should check whether their Unicode build matches the one they get at run-time? How are they going to do that?
They would have to use at least one of the PyUnicode_* APIs in their code. I think it would also be a good idea to provide a non-mangled PyUnicode_UnicodeSize() API which would then return the number of bytes occupied by Py_UNICODE of the Python build. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
participants (3)
-
Guido van Rossum
-
M.-A. Lemburg
-
Martin v. Loewis