RetroSearch Browse

Sun Aug 29 10:24:47 CEST 2010 · https://mail.python.org/pipermail/python-dev/2010-August/103334.html

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"?

Regards

Antoine.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-August/103334.html below:

[Python-Dev] PEP 384 status