[Python-Dev] PEP 384 status

Nick Coghlan ncoghlan at gmail.com
Sun Aug 29 14:16:57 CEST 2010


On Sun, Aug 29, 2010 at 7:10 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 29 Aug 2010 18:41:45 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 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)?

Oh, you meant combining it with the suggested change to the errno
handling rather than merely inlining the existing PyObject_Print? Yes,
that should work and would be even more seamless from the point of
view of the extension modules.

However, since even platforms other than Windows aren't immune to
version upgrades of the standard C runtime, I'm still more comfortable
with the idea that the strict ABI should refuse to pass FILE* pointers
across extension module boundaries. The advantage of the preprocessor
macro approach is that it allows us to provide assistance with
operations on FILE* pointers while still obeying that restriction
regardless of the specific compilers involved in creating the Python
and extension module binaries.

It would be nice to get rid of the resultp parameter by rewriting the
internals of the macro as a collection of ternary and comma
expressions instead of a scope, but I haven't managed to crack the
problem of feeding the correct arguments to fwrite with that approach
(it's been quite a while since I've attempted to abuse C expressions
to this extent, so I've forgotten most of the tricks for avoiding
temporary variables).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list