> How about you learn a few things about the language before you support it?

First you randomly picked an encoding (utf8), and then claimed that, because you picked the wrong encoding, Python's unicode implementation is broken? In a perfect world there would only be one representation of the data on disk, but we have to deal with a lot of different encodings. That's when you make a decent effort to guess, and give the user a prompt in cases where you can't identify the data. You seem to be assuming that users never want to read the data, and that all you're doing is tunneling it from one place to another, which is perfectly fine if all you're doing is writing a proxy script or the like. However, at some point the user is going to want to look at the data, and there's exactly no way at all to present it if you don't know what format it's in. After all, if you don't know the format, you can't manipulate anything, and unless your goal is to reimplement 'dd', what use is your program?

> So you're saying that you'd rather destroy user's data than do the right thing?

If it's supposed to be utf8, but it's got broken characters, it's already been destroyed. Unless your definition of the right thing is making a file-copy command that writes out exactly what it reads in, you're making assumptions about the input data that you can't verify without handling the encoding to some degree. What if the input is actually utf-16? Then suddenly all your functions that iterate line-by-line will destroy the data because the EOL is two bytes, and depending on how well you're handling the rest of the data, you might end up with nothing at all -- since utf-16 contains null bytes within the string itself.

You still have yet to supply anything to support your argument. All you're doing is hand-waving.