> my good friend the mad scientist (the guy who writes code, > not the flaming cult-ridden brainwashed script kiddie) has > considered writing a whole new "abstract file" backend, to > entirely get rid of stdio in the Python core. some potential > advantages: > > -- performance (some stdio implementations are slow) > -- portability (stdio doesn't exist on some platforms!) You have this backwards -- you'd have to port the abstract backend first! Also don't forget that a *good* stdio might be using all sorts of platform-specific tricks that you'd have to copy to match its performance. > -- opens up for cool extensions (memory mapping, > pluggable file handlers, etc). > > should I tell him to start hacking? Tcl/Tk does this. I see some advantages (e.g. you have more control over and knowledge of how much data is buffered) but also some disadvantages (more work to port, harder to use from C), plus tons of changes needed in the rest of Python. I'd say wait until Python 2.0 and let's keep stdio for 1.6. > PS. someone once told me that Perl goes "below" the standard > file I/O system. does anyone here know if that's true, and per- > haps even explain how they're doing that... Probably just means that they use the C equivalent of os.open() and friends. --Guido van Rossum (home page: http://www.python.org/~guido/)
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