[Csv] Re: First Cut at CSV PEP

[Dave Cole]

    Cliff> Export is a slightly different story.  I do think None should be
    Cliff> mapped to '' on export since that is the only reasonable value
    Cliff> for it, and there are enough existing modules that use None to
    Cliff> represent an empty value that this would be a reasonable thing
    Cliff> for us to handle.

Skip> How is a database (that was Dave's use case) supposed to
Skip> distinguish '' as SQL NULL vs '' as an empty string though?
Skip> This is the sort of thing that bothers me about mapping None to
Skip> ''.

    Cliff> This might not affect performance too badly if we *always* raise
    Cliff> an exception when passed anything but a string, ...

Skip> except float and int values will be prevalent in the data.

Skip> Can we limit the data to float, int, plain strings, Unicode and
Skip> None?  If so, I think you can just test the object types and do
Skip> the right thing.  In the case of None, I'd like to see a
Skip> parameter which would allow me to flag that as an error.  The
Skip> extra complication might be limited to
Skip> 
Skip>     map_none_to='some string, possibly empty'
Skip> 
Skip> in the writer() constructor and
Skip> 
Skip>     interpret_empty_string_as=<any object, maybe None>
Skip> 
Skip> in the reader() constructor.

I think that we should have an option (or set of options) which causes
the following:

* In the writer, export None as the unquoted string 'null'.

* In the write, export the string 'null' as the quoted string "null".

* In the reader, import the unquoted string 'null' as None.

* In the reader, import of the quoted string "null" as 'null'.

This solves the ambiguity for the case when we are in control of the
round trip.  When we are not in control of the round trip all bets are
off anyway since there is no standard (that I know of) for expressing
this.

- Dave


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