Please consider the enclosed patch to fileinput.py,
which  implements an openfile method of FileInput. 
Included is a use case bz2fileinput.py.

Logged In: YES 
user_id=987664

Hmmm. This could be useful. Pythonistas could also supply
openfile for, say, URLs as well. I'm kind of lukewarm on it
for some reason--I think that you'd be better off
decompressing the data somewhere else. I also did some
benchmarking the other day and found that fileinput is
really, really slow.

I don't understand the change from Fileinput to _Fileinput.
You're going to need to fix the inplace stuff in
Fileinput.readline().

This needs documentation, and a more detailed description.

Please provide a patch against the latest CVS instead of
Python 2.3.

Logged In: YES 
user_id=1188172

In addition to hoffmanm's question about the renaming of
FileInput, two issues:
- An additional module, especially with only a few lines in
it, is not going to be accepted into the stdlib. This is
better done in your own code, where you know what types of
files you will encounter.
See patch #1215184, which implements a similar openhook for
fileinput.
- Only bz2 is too selective. You would have to have modules
"gzfileinput", "urlfileinput", etc. Too much name crowding.

For these reasons, rejecting this patch.

Logged In: YES 
user_id=252223

Sorry for not responding in time to those questions.

My proposal was meant to provide the openfile method, and
provide the user with a way to override it and still use the
static infrastructure if the fileinput module, as
demonstrated by bz2fileinput.py.

Instead of using the hook "_FileInput" to provide a
replacement class to the module, it may be better to replace
FileInput.openfile() in derived modules, but I thought that
may be even more of a hack.

If you think this is worth following up, please advise of
the best way to achieve this goal.

Thanks
Stephan