[Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?

[Tim Peters]

[Guido]
> I expect that the right solution here is indeed to write our own
> stdio-like library from the ground up.  That can solve any number of
> problems: telling how many characters are buffered (so you don't have
> to use unbuffered mode when using select or poll), platform-
> independent line end recognition, and super-efficient readline()
> to boot.

We also have the old

    http://sourceforge.net/tracker/?group_id=5470&
        atid=105470&func=detail&aid=210821

complaining that use of FILE* in our C API can make it impossible to (in that
fellow's case) write an app in Borland C++ on Windows that tries to use those
API functions (cuz Borland's FILE* is incompatible with MS's FILE*).  I'm not
sure the best solution to *that* is to give them a FILE* that's incompatible
with everyone's, though <wink>>

> But it's a lot of work, and won't be compatible with existing
> extensions that use FILE* (not too many I believe).

I'm more concerned about the "lot of work" part, with which I agree.

OTOH, Plauger's book "The Standard C Library" contains source code for every
library required by C89.  He reported that implementing libm took him twice
as long as everything else combined.  But those who haven't written a libm
will be prone to take a wrong lesson from that <wink>.

it's-not-that-i/o-is-easy-despite-that-his-libm-code-isn't-production-
    quality-ly y'rs  - tim