Charles Cazabon wrote: > os.fsync() breakage is a /big/ problem, particularly because the resulting > traceback makes users think the application is broken, not the interpreter. It's not broken: it's absent. In a sense, the application /is/ broken, as it should have dealt with os.fsync being absent in the first place. Applications should be prepared that POSIX functions are not available in Python even if the C library provides them on the system, as the system headers may fail to declare a prototype for the function (a problem which triggered that erroneous change in 2.3.1 in the first place). Python is taking the address of fsync, so merely having the function in the C library is not enough, nor is it to define fsync as a function-style macro. In either case, os.fsync will be rightfully absent. FWIW, it was a Redhat system that failed to provide a fsync prototype. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4