On Mar 21, 3:15 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Wed, 21 Mar 2007 00:46:03 -0300, John Pye
> <[EMAIL PROTECTED]> escribió:
>
> > This is not an option for me, as I want to pass the
> > FILE* from Python and all the way into into a existing shared-library
> > code. I can't change the latter; it must work ok with standard fprintf
> > (etc) functions.
>
> You can get the file descriptor from the Python file object using its
> fileno() method. The file descriptor lives at the OS level, so it's safe
> to pass around. You can regenerate a new FILE struct (using the other
> runtime library) with fdopen.
>
> --
> Gabriel Genellina
Hmm. Reading this again I think I understand properly now. The
'fileno' is really *not* the same thing as the FILE* pointer cast to
an integer. It is a lower-level structure.
The question is now, if I don't want to modify my *python* code, how
do I get at the 'fileno' property of my PyFileObject?
Also, are there consequences for using this approach of regenerating
the FILE struct? For example if I have the following:
F = os.tmpfile()
F.write("some data")
F.seek(0)
myswigmodule.dosomething(F)
F.seek(0)
S = F.read()
print S
I don't know enough about this low-level file handling to really
understand the implications of what you are proposing -- perhaps you
could explain a little?
Cheers
JP
--
http://mail.python.org/mailman/listinfo/python-list
