[Python-Dev] PEP 384 status (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Sun Aug 29 11:10:43 CEST 2010

On Sun, 29 Aug 2010 18:41:45 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote:

On Sun, Aug 29, 2010 at 6:24 PM, Antoine Pitrou <solipsis at pitrou.net> wrote: > On Sun, 29 Aug 2010 09:20:56 +1000 > Nick Coghlan <ncoghlan at 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 PyObjectPrint out of the limited API, but create a >> PyObjectPrintEx that takes a Python IO stream via PyObject* rather >> than a C level FILE*. >> - leave PyObjectPrint out of the limited API, but create a >> PyObjectPrintEx 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 PyObjectPrint out of the limited API, but create a >> PyObjectPRINT 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 PyObjectPrint() 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.

More information about the Python-Dev mailing list