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