RE: [Python-Dev] End of the line

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... Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

[Tim, on the cheating PerlIO API] [Brian Lloyd]
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

let's-model-PythonIO-on-the-win32-api<wink>-ly y'rs - tim
Interestingly, this raises a point worth mentioning sans-wink :-) Win32 has quite a nice concept that file handles (nearly all handles really) are "waitable". Indeed, in the Win32 world, this feature usually prevents me from using the "threading" module - I need to wait on objects other than threads or locks (usually files, but sometimes child processes). I also usually need a "wait for the first one of these objects", which threading doesnt provide, but that is a digression... What Im getting at is that a Python IO model should maybe go a little further than "tradtional" IO - asynchronous IO and synchronisation capabilities should also be specified. Of course, these would be optional, but it would be excellent if a platform could easily slot into pre-defined Python semantics if possible. Is this reasonable, or really simply too hard to abstract in the manner I an talking!? Mark.

[Tim, on the cheating PerlIO API] [Brian Lloyd]
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

let's-model-PythonIO-on-the-win32-api<wink>-ly y'rs - tim
Interestingly, this raises a point worth mentioning sans-wink :-) Win32 has quite a nice concept that file handles (nearly all handles really) are "waitable". Indeed, in the Win32 world, this feature usually prevents me from using the "threading" module - I need to wait on objects other than threads or locks (usually files, but sometimes child processes). I also usually need a "wait for the first one of these objects", which threading doesnt provide, but that is a digression... What Im getting at is that a Python IO model should maybe go a little further than "tradtional" IO - asynchronous IO and synchronisation capabilities should also be specified. Of course, these would be optional, but it would be excellent if a platform could easily slot into pre-defined Python semantics if possible. Is this reasonable, or really simply too hard to abstract in the manner I an talking!? Mark.
participants (3)
-
Brian Lloyd
-
Mark Hammond
-
Tim Peters