Should a file being read be required to have a single line termination type, or could they be mixed and matched? The prototype code allows mix and match, but I'm not married to that idea. If it requires a single terminator, then some performance could be gained by checking the terminator type when opening the file, and using the existing native text file code when it is a native file.
I'm not aware of any type of text file, that supports switching line deliminators inside of the same file.... Now that doesn't mean it couldn't exist, but logically that would be a strange file.... I think it's a even bet that a file would have the same deliminator throughout the file.
My proposed solution to these problems is to have a new type of file: a "Universal" text file. This would be a text file that would do line-feed translation to the internal representation on the fly as the file was being read (like the current text file type), but it would translate any of the known text file formats automatically (\r\n, \r, \n Any others???).
That would be a interesting idea... I'm not sure how much of a performance hit we'd see, but that would certainly solve a PC / MAC issue I'm having.... (Any chance we could see the code?) Regarding your points on changing the default text file type.... There are several different ways to solve this. * Don't have the Universal be the default text file type, instead offer it as a different class, or as a open('garbage.txt', "r", universal), or some other optional switch. - Advantages being that this allows the programmer to control of the Universal usage. * Just the opposite, the programmer explicitly tells Python not to support universal... * Have the programmer subclass the File Type? * Add a global directive? * Specifically import a "universal" which will depreciate the "standard" text file IO routines... * Actually I think this sounds like the easiest and fastest way to deal with it. This way, you could add a extension library to speed it up, or whatever... (This idea is very much along the lines (??) of the STRING / STROP import) - Benjamin