On Thu, 2013-01-24 at 16:17 +0000, Mark Hackett wrote:

...

That said, what are your feelings on adding a CarefulDictReader?

It's as good a solution to me as any.

However, I'm not that good a programmer, and therefore what *I'd* do isn't necessarily a good idea, it's just one of the better ones out of the limited toolbox I have available.

I'd prefer (for aesthetic reasons) some sort of stream converter. Much like freeze/thaw serialisation of data, it'd be a step between the raw csv and the reader that reads it.

I think my reason for wanting to have a CarefulDictReader (or a careful DictReader), and why I think a stream converter isn't the best solution, is that CSVs are very commonly used by people just starting to get their feet wet with programming. Consider the use case: I've got my excel file, and I'm just getting to the point where excel isn't cutting it anymore. I want to start manipulating my data with python, and everyone is telling me to use the csv library. DictReader sounds cool, because I don't want to have to remember column numbers, and this is going make my code much more readable. But I can't make it read my headers simply because I put some blank space at the top of my excel file, above my headers. A stream converter is another layer of complexity that keeps this potential new programmer from having a good experience with programming, for what gain? So that the csv library can "properly" (?) treat a line without data as a header? I think it would be fully reasonable (and add little to no complexity to the code) to have a DictReader that treats the first non-empty line as the header row. The csv module is one of the big gateways into python programming for a lot of people. That's also one of the reasons I think the sockets library is a poor analogue here. A new programmer is unlikely to reach the sockets library until they've been through a few of the urllibs, the httplibs, requests, some part of http or an external web framework, smtplib, or some other higher-level networking-related libraries. For the same reason, I think if the solution isn't something handled automatically by the library, it needs to be accompanied by improvements to the documentation. If we're going to provide a DictReader that is this easy to break, we need to answer the question: How do I fix it? Cheers, Cliff