On Sun, Aug 29, 2010 at 6:24 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 29 Aug 2010 09:20:56 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
Four options come to mind:
- just leave it out of the limited API, extensions can do their own thing to print objects - leave PyObject_Print out of the limited API, but create a PyObject_PrintEx that takes a Python IO stream via PyObject* rather than a C level FILE*. - leave PyObject_Print out of the limited API, but create a PyObject_PrintEx that takes function pointers for the above 4 operations (so the FILE* pointer is only every operated on by functions from the extension module's CRT) - leave PyObject_Print out of the limited API, but create a PyObject_PRINT macro that does much the same thing with the logic rearranged so there is an inner function that figures out the string to be printed, but an outer macro that does all the operations on the FILE * object (so again, the FILE * is never passed to Python's CRT)
Fifth option: - make PyObject_Print() an inline function (similar to your macro proposal), but only on Windows. This would retain the name and current signature. Apparently we could use something like "__forceinline" or "extern __forceinline"?
I believe both that option, and my third option, would run into trouble due to the potential for errno confusion. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia