> 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.
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