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