[Python-Dev] PEP 384 status (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Sun Aug 29 11:10:43 CEST 2010
- Previous message: [Python-Dev] PEP 384 status
- Next message: [Python-Dev] PEP 384 status
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: [Python-Dev] PEP 384 status
- Next message: [Python-Dev] PEP 384 status
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]