[CSV] Re: First Cut at CSV PEP

Dave Cole djc at object-craft.com.au
Wed Jan 29 04:45:10 CET 2003


>>>>> "Skip" == Skip Montanaro <skip at pobox.com> writes:

Skip> I'm not so sure this mapping None to "None" on output is such a
Skip> good idea because it's not reversible in all situations and
Skip> hurts portability to other systems (e.g., does Excel have a
Skip> concept of None? what happens if you have a text field which
Skip> just happens to contain "None"?).

Dave> I think that None should always be written as a zero length
Dave> field, and always read as the field value 'None'

Skip> I'm really skeptical of this.  There is just no equivalence
Skip> between None and ''.  Right now using the Object Craft csv
Skip> module, a blank field comes through as an empty string.  I think
Skip> that's the correct behavior.

I think I was unnecessarily clumsy in my explanation.  This is what I
was trying to say:

>>> w = csv.writer(sys.stdio)
>>> w.write(['','hello',None])
',hello,\n'
>>> r = csv.reader(StringIO('None,hello,'))
>>> for l in csv: print r
['None','hello','']

Skip> I think we need to limit the data which can be output to
Skip> strings, Unicode strings (if we use an encoded stream), floats
Skip> and ints.  Anything else should raise TypeError.

Dave> Is there any merit having the writer handling non-string data by
Dave> producing an empty field for None, and the result of
Dave> PyObject_Str() for all other values?

Skip> I'm not sure.  I'm inclined to not allow anything other than
Skip> what I said above.  Certainly, compound objects should raise
Skip> exceptions.  I think of CSV more like XML-RPC than Pyro.  We're
Skip> trying to exchange data with as many other languages and
Skip> applications as possible, not create a new protocol for
Skip> exchanging data with other Python programs.  CSV is designed to
Skip> represent the numeric and string values in spreadsheets and
Skip> databases.  Going too far beyond that seems like out-of-scope to
Skip> me, especially if this is to get into 2.3.  Remember, 2.3a1 is
Skip> already out there!

OK.  The current version of the CSV module does what I was suggesting.
We will just have to remove that code.

Dave> That raises another implementation issue.  If you export from
Dave> Excel, does it always quote fields?  If not then the default
Dave> dialect behaviour should not unconditionally quote fields.

Skip> Not in my limited experience.  It quotes only where necessary
Skip> (fields containing delimiters or starting with the quote
Skip> character).

Dave> We could/should support mandatoryquote as a writer option.

Skip> This is something Laurence Tratt's original CSV module did (his
Skip> ASV module probably does as well).  I used it all the time.
Skip> Gnumeric provides "always", "as needed" and "never".  I don't
Skip> know how you'd do "never" without specifying an escape
Skip> character.  I just tried "never" while saving CSV data from
Skip> Gnumeric.  It didn't escape embedded commas, so it effectively
Skip> toasted the data.

I have seen that happen in other applications.

- Dave

-- 
http://www.object-craft.com.au

_______________________________________________
Csv mailing list
Csv at mail.mojam.com
http://manatee.mojam.com/mailman/listinfo/csv



More information about the Csv mailing list