fileinput module dangerous?

[Chris Connett]

Jorgen Grahn wrote:
[...]
> 
> I can't see how there could be a reason. I'd welcome a patch.

OK, I've gone ahead and made a fix.  It makes use of os.tmpfile if it is 
available, but implements the same (now safe) behavior if it is 
unavailable through other means.

I also searched through old postings about this module, and went over 
various complaints.  I found that unicode awareness was missing and 
wanted, and since there is no other effective way to mimic it in client 
code, I added encoding support.  All my changes *should* be backwards 
compatible, which brings me to my next question.

As someone who has never posted a patch, what are next steps from here. 
  Is there a standard test suite that I need to run?  What about 
documentation updates?

This patch should be considered alpha quality, especially the encoding 
support, though if the module is used without specifying an encoding, it 
should work exactly as before.  Please beat on it, though do note that I 
haven't run any standard test suites if they exist, so bugs may not 
necessarily be obscure ones.  I will continue to run more tests myself 
in the coming days.

Note:
- Due to the buffering nature of fileinput, universal newlines only 
works when using an encoding whose StreamReader's readlines() method 
performs universal newlining.

--
Chris Connett
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fileinput.py.patch
URL: <http://mail.python.org/pipermail/python-list/attachments/20041015/41ca2634/attachment.ksh>