So that *still* leaves the question, "where does it go". Here are some
possibilities:
Stick it into file objects.
- this clutters up file objects
- it doesn't clutter it up much
- it doesn't open the door for file object pollution
- file objects are not in posixmodule, and we don't have
to think of them as posix file handles
Create a "subclass" of fileobject with peeking.
- this keeps fileobject pure
- may help to keep clear the related, safe operations
[Redford 93]
- new peekfileobjects can be passed to programs that
were only expecting fileobjects
- this creates a new class with minimal additional
functionality, and clutters up the set of classes
Create a class of readahead objects.
- this is very general
- it is more work
- not as well understood
- perhaps not as necessary, because we don't need to
readahead on python data structures
- we will not be able to feed programs written for
fileobjects with readahead objects unless there is
a subclass of filereadahead objects.
My personal preference is for the first approach, but if people hate it
we can go for the second. (I find that making excessively precise distinctions
between functional groups is a cluttering as making overly gross distinctions.
But in this case I just don't care that much. The set of techniques for paring
the integuement from a feline has more than one element.) To implement the
second, I'll just create a new builtin module within fileobject.c that will
contain a constructor for class lineio (or something), which will have most of
the methods from fileobject and a couple of new ones.
Tracy Tims
tracy@sni.ca