On 2012-04-26, Tim Roberts <t...@probo.com> wrote: > Neil Cerutti <ne...@norwich.edu> wrote: > >>Is there an explanation or previous dicussion somewhere for the >>following behavior? I haven't yet trolled the csv mailing list >>archive, though that would probably be a good place to check. >> >>Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit >>(Intel)] on win 32 >>Type "help", "copyright", "credits" or "license" for more information. >>>>> import csv >>>>> next(csv.reader(['""\r\n'])) >>[''] >>>>> next(csv.reader(['\r\n'])) >>[] >> >> I hoped or assumed that the 2nd invocation should have the >> same result as the first. > > Really? That's not at all what I would have expected. The > first line contains one field. The second line contains 0 > fields. It's consistent, and syntactically valid. > >> I admit a blank, one-field csv record just isn't very >> insteresting, but isn't this a special case that ought to be >> documented? > > But that's what you have in the first line, and the reader has > returned to you a list containing one (empty) string. > > I just don't see your interpretation. The results are exactly > what I would have expected.
I made the following wrong assumption about the csv EBNF recognized by Python (ignoring record seps): record -> field {delim field} There's at least some csv "standard" documents requiring my interprestion, e.g., http://mastpoint.curzonnassau.com/csv-1203/CSV-1203.pdf but by no means all. That's why I thought it might be something that should be documented rather than discovered. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list