On Wed, Sep 1, 2010 at 1:42 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > What I think would be a mistake would be to define the API in terms of > Windows-specific quirks. All this discussion seems bent on satisfying > the needs of Windows developers at the expense of non-Windows > developers. "FILE*" is a perfectly standard C feature (and a > widely-used one at that). If Windows doesn't handle it correctly then > it's a Windows issue and we shouldn't annoy other people by refusing > access to that feature.
As an alternative the stable ABI could use the native system file handle instead of FILE*. HANDLE (returned by CreateFile) on Windows and int (returned by open) on Linux (or even FILE*). The extension writer would have to write it's own abstraction over this. Python could provide a default wrapper (as a sample). Unfortunately you would also lose the buffering provided by fopen (unless the sample also does this). As a side note, I wrote a plugin for a big Windows application (Mastercam) once. There were at least 5 different CRTs running in that process - 3 different release versions and 2 different debug versions. Besides a few other statically linked into other plugin DLLs. This is quite common, especially since you can have foreign CRTs injected into your process by various shell extensions like TortoiseSVN. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
