[Greg writes] > The main problem with Perl's I/O abstraction layer is that extension > modules now have to call e.g. PerlIO_open(), PerlIO_printf(), etc. in > place of their stdio counterparts. Surprise surprise, many extension Interestingly, Python _nearly_ suffers this problem now. Although Python does use native FILE pointers, this scheme still assumes that Python and the extensions all use the same stdio. I understand that on most Unix system this can be taken for granted. However, to be truly cross-platform, this assumption may not be valid. A case in point is (surprise surprise :-) Windows. Windows has a number of C RTL options, and Python and its extensions must be careful to select the one that shares FILE * and the heap across separately compiled and linked modules. In-fact, Windows comes with an excellent debug version of the C RTL, but this gets in Python's way - if even one (but not all) Python extension attempts to use these debugging features, we die in a big way. and-dont-even-talk-to-me-about-Windows-CE ly, Mark.
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