Re: Ideas about enhancements to fileobjects

jredford@lehman.com
Tue, 23 Nov 93 11:02:57 -0500

>> Of course you can't trust it as the state of the universe, but neither
>> is a count you maintain separately, and if the semantics are
>> understood, it's a convenience that can often avoid having to pass a
>> more complicated object than a file around.

Yes, but what I know as the implementor of the counting isnt what the
average user might know as a user of the module. (mixing cases there).
Is it that much more expensive to pass [fd,5] the fd? If you want
something like a line number in your error message, 'except' the
error in the function that knows the line number, and then raise it
again with a modified arguement. 'line numbers' are not intrinsic to
the concept of a file. readline() & such are for convienience. Files
arent record based. It isnt the efficiency of this that worries me as
much as the lack of a clean way to implement it meaningfully.

>> Well that's why I have some difficulties with it myself. I also have
>> a feeling that it wouldn't be very expensive to implement as a Python
>> class which would act as a wrapper around a file object and used only
>> when needed.

Oh, indeed. Subclasses are allowed to do whatever they like.

>> > Oh, and this would definitely encourage bad style. _using_ it is bad
>> > style.
>>
>> Well if you write a certain kind of parsing code it may be very good
>> style.

Only if it is clear this is a distinct interface. Pretending 'files'
are peekable is a broken way of looking at files. The fact that
regular files are random access means there is no gaurentee that what
you peek will be what you get, unlike sockets, pipes & so forth.

>> Mind your language! Keeping the filename is zero overhead, keeping
>> the lineno would be one instruction per readline call. (The overhead
>> for read() could be reduced to that by setting it to -1 then.)
>> Anyway, "parser" is a word that can mean a lot of things -- in a sense
>> any program that scans a file can be called a parser, even though it
>> may not have a notion of a grammar. And what begins as a program to
>> search for very simple patterns may over time evolve to a fairly
>> complex parser. Python will be used during the transition phase from
>> grep job to C program...

I was refering to the peeking. It would be needless overhead and
complexity when the author should either use seek or multiple file
objects.

>> Eh, not everybody on the list may know what you mean. I presume with
>> M3 you mean Modula-3. But what is Sx?

Yes, Modula-3. Sx is the Symbolic expression interface. it can read:
(2, [3,4], (1,'foo','bar'))
as plain text, and convert it to a List.T containing elements pointing
to an INTEGER, an ARRAY, and another List.T. Additionally you can
define tokens which are converted to something pre-defined:

(Text "quit") -> List.T -> 4 (* Assuming 'Text' was bound to integer 4 *)
|
List.T -> "quit"

This is what the SRC-Modula-3 compiler uses to parse Modula-3 code.
FormsVBT also uses this interface. It seems like it would be easy
enough to do in Python, and it would provide a good generic parser.

--
John Redford (AKA GArrow) | 3,600 hours of tape.
jredford@lehman.com       | 5 cans of Scotchguard.