[Tim, on the cheating PerlIO API] [Brian Lloyd] > Hmm - speed bonuses not withstanding, an implementation of > such a beast in the Python sources would've helped a lot to > reduce the ugly hairy gymnastics required to get Python going > on Win CE, where (until very recently) there was no concept > of most of the things you expect to find in stdio... I don't think it would have helped you there. If e.g. ftell is missing, it's no easier to implement it yourself under the name "PerlIO_ftell" than under the name "ftell" ... Back before Larry Wall got it into in his head that Perl is a grand metaphor for freedom and creativity (or whatever), he justifiably claimed that Perl's great achievement was in taming Unix. Which it did! Perl essentially defined yet a 537th variation of libc/shell/tool semantics, but in a way that worked the same across its 536 Unix hosts. The PerlIO API is a great help with *that*: if a platform is a little off kilter in its implementation of one of these functions, Perl can use a corresponding PerlIO wrapper to hide the shortcoming in a platform-specific file, and the rest of Perl blissfully assumes everything works the same everywhere. That's a good, cool idea. Ironically, Perl does more to hide gratuitous platform differences here than Python does! But it's just a pile of names if you've got no stdio to build on. let's-model-PythonIO-on-the-win32-api<wink>-ly y'rs - tim
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