Some Python 2.1 ideas

[Bjorn Pettersen]

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).

-- bjorn