[Python-Dev] PEP 384 status

[Antoine Pitrou]

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 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.