[Pythonmac-SIG] Using a unix Python with a MacPython Lib tree

[Jonathan Wight]

On 04/03/2001 13:47, "Steven D. Majewski" <sdm7g@Virginia.EDU> wrote:

>> For MacPython I could hack the low-level stdio routine that does CR->LF
>> conversion, which would treat both CR and LF as line-end. Note that this is
>> different from trying to fix it in MacPython itself, which I've always been
>> reluctant to do because of various side-effects. On output \n would be
>> translated to \r, as happens now, on input both \r and \n would be mapped to
>> \n.
>> 
>> If the same could be done for BSD-Python The any text file should be readable
>> as text from both runtimemodels.
> 
> It would be nice if we could coax at least one of them to be more liberal
> in what it accepts. Probably, the stdio lib sources are in the open source
> Darwin -- we could probably hack that into a replacement lib that takes
> both line endings.

I've hit upon a similar problem with my ToxicEdit project. By default
sys.stdout and sys.stderr refer to the stdc stdout and stderr. So to get
output go to my console window instead of the system's stdout/stderr I had
to replace sys.stdout/sys.stderr with my own fake file objects.

This would have been incredibly simplified if I could have registered my own
C callbacks as the 'destination' of stdout/stderr. Unfortunately the Python
source code is pretty dependent on the stdio functions and you'll see FILE *
littered throughout the Python code.

One idea that would have simplified my problem (and anyone else who is
embedding Python) and can fix the LF/CR return problem is to replace the
stdio FILE * and stdio function calls. On all platforms without the LF/CR
problem you could just do something like:

    #define PYIO_FILE       FILE
    #define PYIO_fprintf    fprintf
    #define PYIO_fgets      fgets

And so on. All you'd need to do then is do a quick search/replace through
the Python source code to update it.

This would allow us to replace all the ascii IO code with code that handled
the LF/CR problem transparently. And of course this would help me with my
embedding problems.

This would be a pretty big change to the Python source code though akin to
the 'great renaming' of a few years ago.

    Jon.