[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