[Pythonmac-SIG] Mac Python and line-endings

Schollnick, Benjamin Benjamin.Schollnick@usa.xerox.com
Tue, 18 Sep 2001 14:49:19 -0400


> 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