Some Python 2.1 ideas

[Donn Cave]

Quoth Bjorn Pettersen <pbjorn at uswest.net>:
| Donn Cave wrote:
|> Quoth Bjorn Pettersen <pbjorn at uswest.net>:
|> D-Man wrote:
|>|> Yeah, it is a problem if you don't know where the file came from.  How
|>|> about creating a standard text file format?  All files could be opened
|>|> in binary mode on all platforms, then EOL is handled by each
|>|> application (or better yet make a standard module that does the
|>|> implementation correctly once).
|>|
|>| Feeling like fighting windmills today, eh <wink>? I think the current wish is to
|>| do it from the other end, i.e. instead of relying on the text file format to be
|>| "correct", implement a method on string object that is smart enough to handle all
|>| text file format line endings intelligently.
|>
|> Without the context of the I/O stream, to decide whether '\r' is
|> data or separator, isn't that string function going to be the opposite
|> of smart?  How does a string handle '\r' intelligently?
|
| By assuming that if it's the last character in the string, it came from a mac file and
| is the line terminator. Similarly for '\r\n' (dos) and '\n' (unix) when at the end of
| the string.
|
| It might be cute to have a MacTextFile class etc. that ensures that the line endings
| are consistent, but personally I think that is overkill (and is likely to be very
| slow).

I guess a function like that would often be the right thing.  But
it doesn't strike me as what I would have called intelligent handling,
just aggressive in its assumptions.  In a situation where the application
calls for an aggressive normalization of the data, it's obviously the
right thing.  Otherwise, it's useless, where a per I/O stream solution
might still be useful, and I guess cute too.

	Donn Cave, donn at u.washington.edu