On Sun, 29 Aug 2010 18:41:45 +1000 Nick Coghlan <ncogh...@gmail.com> wrote:
> 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. I don't understand. What's the difference with the macro you proposed (the fourth option)? Antoine. _______________________________________________ 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
