On Thursday 18 July 2002 01:39 am, Greg Ewing wrote: > Alex Martelli <aleax@aleax.it>: > > the file object's is the only example of "fat interface" problem > > in Python -- an interface that exposes a lot of methods, with many > > objects claiming they implement that interface but actually lying > > Maybe the existing file object should be split up into > some number of other objects with smaller interfaces. In an ideal world, yes. In practice, I strongly doubt it's feasible to break backwards compatibility THAT heavily. > For example, instead of the file object actually accessing an > OS file itself, it could just be a wrapper around an > underlying "bytestream" object, which implements only > read() and write(). I suspect read and write would best be kept on separate interfaces. Ability to read, write, seek-and-tell, being three atoms of which it makes sense to have about 6 combos (R, W, R+W, each with or without S&T). Rewind might make sense separately from S&T if streaming tapes were still in fashion and OS's gave natural access to them. But I do think it's all pretty academic. Alex
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