extending file?

[Bengt Richter]

On Tue, 02 Nov 2004 12:13:34 -0500, Jeremy Jones <zanesdad at bellsouth.net> wrote:

><snip the whole thread>
>
>So, with everything being said that's been said, here's are two 
>questions for myself and for Chris Cioffi:
>
>1.  How difficult would it be to modify file.readline() so it would read 
>until a specific character rather than the standard end of line 
>character(s)?
>2.  What would be the best way to go about the above?
>
>If anyone has any ideas, I think we would both listen with great interest.
>
>
Maybe this general idea could give you a way to install your own custom solution
without an app-specific custom mod to file or open:

I'd like to see a file/open hook in sys (or maybe os), so that you could intercept the open
operation for specific file paths registered with the hook. E.g., if it were a
simple directory

    sys.filehook['foo.txt'] = MyFileClass # or callable factory

would cause file('foo.txt', mode, kwarg=something) to look in sys.filehook before going to the normal
file system, and return MyFileClass('foo.txt', mode, kwarg) instead of the normal file object. (I.e.,
file & open would be extended to accept *args, **kw to pass through to hooks if present)

This would allow passing custom input sequences as file-like objects to programs whose interface
is a file path string, and obviously you could use the file path arg passed through to open/file
to open a real file that you wanted to filter in some way (assuming you temporarily at least
removed the hook, or had an alias to the unhooked open function).

I don't think this would be hard to implement, but I haven't thought it through.
Gotta go vote. And other stuff...

An extension of this idea would be to allow registering patterns like
    sys.filehook['*.cfg'] = MyConfigFilter
where a mathing open would pass through the actual matched path.


Regards,
Bengt Richter