passing FILE pointers to a non-MSVC++ compiled extension type???

[Alex Martelli]

"doug" <doug_bartholomew99 at yahoo.com> wrote in message
news:e71960c5.0108111158.6ea4e650 at posting.google.com...
    ...
> 1) what is the correct way to construct the Python file-like object?
> Having looked at the documentation and the source, i put together:
>
>    PyObject* py_file = PyFile_FromFile(fp, "somename", "DUNNO", NULL);
>    PyFile_WriteString(char_pointer, py_file);
>    Py_XDECREF(py_file);
>
> which does in fact work fine.  but what do the name, mode and close
> arguments of PyFile_FromFile() actually do?  i dont want to accidently
> create a bug that ill never be able to track down in 6 months.

The name, mode and close arguments to PyFile_FromFile are
saved in the slots f_name, f_mode and f_close of the Python
file object.  .name and .mode become attributes you can
access from your Python code; f_close, if not null, is a
function that's automatically called when the Python file
object is being finalized.  To be pedantic I guess you should
pass "w" as the mode argument -- it's not used today (and I
doubt it will be used in the future), but why not do it right.


> 2) the first argument to PyFile_WriteString() is a char*.  shouldnt
> this be a const char* type?  surely PyFile_WriteString() doesnt need
> to make any changes to the string.  i tried to be const correct and
> pass in a const char* but it generated a compiler error.

Right, no doubt.  But that argument is passed to fputs, and I
guess having it as char* rather than const char* makes life
easier when dealing with non-const-correct oldish C libraries.
(I think it could be changed now that Python requires an ISO
compliant C compiler and library, though).


Alex