On Sun, Aug 29, 2010 at 6:24 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Sun, 29 Aug 2010 09:20:56 +1000 > Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
