csv: No fields, or one field?

[Neil Cerutti]

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. This is not defined anywhere except in a
comment in _csv.c, as far as I can tell. There is no test in
test_csv.py verifying the behavior, either, that I found.

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? The reader requires a blank, one-field record to be
defined with a quoted field, but it doesn't say so in the
documentation.

csv.writer is commutative with the reader in this case though, as
it emits '""\r\n' if you ask it to writerow(['']). This is
surprising given the definition of QUOTE_MINIMAL, which fails to
mention this special case.

csv.QUOTE_MINIMAL

Instructs writer objects to only quote those fields which
contain special characters such as delimiter, quotechar or any
of the characters in lineterminator.

 

[Neil Cerutti]

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']))

[]

This should be documented (I trust you when you say it isn't),
but it makes a lot of sense:

next(csv.reader([''])) []
next(csv.reader(['""'])) ['']
next(csv.reader([','])) ['', '']
next(csv.reader([',,']))

['', '', '']

It is definitely consistent and usable, once the quoting truck is
learned.

 

[Neil Cerutti]

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]

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.

Of particular note, a recent patch added a reference to RFC4180
(though not stating that it is compliant), which also does not
recognize zero field length records.