Some Python 2.1 ideas

Bjorn Pettersen pbjorn at uswest.net
Thu Dec 28 15:48:35 EST 2000


Donn Cave wrote:

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

I guess we're in violent agreement <wink>.  I provided a patch to implement chomp(), so I'll
leave it to you to implement a  patch for the other solution ;-)

-- bjorn





More information about the Python-list mailing list