[This is more or less a roll-up summary reply here] At 02:28 PM 9/30/2001 -0400, Guido van Rossum wrote: > > File operations and network operations are fundamental to the interpreter, > > so dedicating opcodes to them makes sense. The I/O system's also fully > > async (where possible, and looking async where it isn't) so we need some > > good hooks into the interpreter for that anyway. > >That may be Perl's philosophy. In Python, file and network ops are >purely a library issue. Hooks for async stuff are something >different; Python currently doesn't have them but I expecte this would >be useful.
The I/O support in the interpreter is reasonably simple, and straightforward. The ops are: open channel close channel async read async write sync read sync write wait for async op to finish seek to X tell push filter on channel stream status Building them in as base functionality makes sense because: *) We can't implement any sort of security or resource limitations if we don't *) If we want working async I/O the interpreter needs to manage it (And almost nobody knows how to write async I/O code anyway, so we'll minimize the damage) *) If the interpreter knows about I/O it can take shortcuts for efficiency (like reading a whole file into an array via mmap with twiddled string structs marked COW) *) We're essentially the OS for programs running on top of us, so we get to provide the LCD. *) It's the best way to get coherent I/O semantics in a multi-language environment *) Parrot's allowing filters to be pushed in the I/O streams, so something (Like, say, Parrot...) needs to manage them This doesn't mean the interpreter will provide all the file open functionality. There will be hooks in there for custom handlers so, for example, if someone wants to take filenames of the form "http://...."; and fetch the data from a webserver like it's a read-only file locally, well, that's OK with me. The socket functions will be in a separately loaded module and, while they'll work properly as channel data sources or sinks, they won't be required. (Both because we want to run on Palms and WinCE machines, and because we don't want to bother paying the startup costs to resolve the symbols in the socket library if we're not actually using 'em) Directory handling operations will *not* be special, though they may fall in the "predefined user ops" category because they've a fixed set of inputs and outputs so they're doable that way. They also won't be required as part of the core interpreter. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
