On 2017-12-06 00:06, Steve D'Aprano wrote: > On Wed, 6 Dec 2017 04:20 am, Jason wrote: > >> I ran into this: >> > https://stackoverflow.com/questions/27707581/why-does-csv-dictreader-skip-emp ty-lines >> >> # unlike the basic reader, we prefer not to return blanks, >> # because we will typically wind up with a dict full of None >> # values >> >> while iterating over two files, which are line-by-line corresponding. The >> DictReader skipped ahead many lines breaking the line-by-line >> correspondence. > > Um... this doesn't follow. If they are line-by-line corresponding, then they > should skip the same number of blank lines and read the same number of > non-blank lines. > > Even if one file has blanks and the other does not, if you iterate the over > the records themselves, they should keep their correspondence. > > I'm afraid that if you want to convince me this is a buggy design, you need to > demonstrate a simple pair of CSV files where the non-blank lines are > corresponding (possibly with differing numbers of blanks in between) but the > CSV readers get out of alignment somehow. > > >> And I want to argue that the difference of behavior should be considered a >> bug. It should be considered as such because: 1. I need to know what's in >> the file to know what class to use. > > Sure. But blank lines don't tell you what class to use. > >> The file content should not break at-least-1-record-per-line. > > Blank lines DO break that requirement. A blank line is not a record. > > >> There may me multiple lines per record in the >> case of embedded new lines, but it should never no record per line. > > I disagree. A blank line is not a record. If I have (say) five fields, then: > > ,,,,\n > > is a blank record with five empty fields. \n alone is just a blank. The > DictReader correctly returns records with blank fields. > A blank line could be a record if there's only one field and it's empty.
[snip] -- https://mail.python.org/mailman/listinfo/python-list