Not overly, no. You seem to not realize that your lookahead
abstraction could be implemented efficiently with seek.
>> So that *still* leaves the question, "where does it go". Here are some
>> possibilities:
>>
>> Stick it into file objects.
>> - this clutters up file objects
true.
>> - it doesn't clutter it up much
true.
>> - it doesn't open the door for file object pollution
false.
>> - file objects are not in posixmodule, and we don't have
>> to think of them as posix file handles
true, but that dosent mean you shoudlnt.
>>
>> Create a "subclass" of fileobject with peeking.
>> - this keeps fileobject pure
true.
>> - may help to keep clear the related, safe operations
>> [Redford 93]
true.
>> - new peekfileobjects can be passed to programs that
>> were only expecting fileobjects
true.
>> - this creates a new class with minimal additional
>> functionality, and clutters up the set of classes
true/false. If its so minimal, hand code it in your app. Just how does
having a subclass clutter anything? No one who uses fileobjects need
know. If you think that a single subclass is too much, maybe you
should go use a non-OOish language.
>> Create a class of readahead objects.
>> - this is very general
Very vague I would say.
>> - it is more work
Not for me. It is less work for the end users.
>> - not as well understood
Because nothing has been said.
>> - perhaps not as necessary, because we don't need to
>> readahead on python data structures
But you do need it on things that arent file objects, like sockets,
unless you wish to force one to use file semantics for them.
>> - we will not be able to feed programs written for
>> fileobjects with readahead objects unless there is
>> a subclass of filereadahead objects.
Or unless readaheads can init from another class and instantiate its
methods as well. You need generics here.
>> 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.
We definitely have distinct styles. I dont see any reason to write
this peekaboo stuff in C, much less to place it in fileobject.c. Write
a subclass, any way you like, any you shouldnt need to touch the
original. Or the original's code. Or even SEE that code, as it is
inherited.
I'm going to assume that if anyone else cares they'll say something.
I'm dropping this issue. Python has just a few problems I dislike, but
module impurity is near the top of the list. Anyone familiar with
Modula-3 shold appreciate the difference between a layered approach,
with generic Rd/Wr types, and the python 'C with foam padding'
approach.
-- John Redford (AKA GArrow) | 3,600 hours of tape. jredford@lehman.com | 5 cans of Scotchguard.