[Python-Dev] PEP 384 status

[Nick Coghlan]

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 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   |   ncoghlan at gmail.com   |   Brisbane, Australia