[Csv] Status

[Skip Montanaro]

    >> * We're still undecided about None (I certainly don't think it's a
    >>   valid value to be writing to CSV files)

    Andrew> I suspect we're in violent agreement? If the user happens to
    Andrew> pass None, it should be written as a null field. On input, a
    Andrew> null field should be returned as a zero length string. Is that
    Andrew> what you were suggesting?

Not really.  In my mind, if I try to write

    [5.0, "marty", "golden slippers", None]

then I have a bug somewhere.  I *don't* want None silently converted to ''.

    >> * Don't raise exceptions needlessly.  For example, specifying
    >> quoting="never" and not specifying a value for escape_char would be
    >> okay until you encounter a field when writing which contains the
    >> delimiter.

    Andrew> I don't like this specific one. Because it depends on the data,
    Andrew> the module user may not pick up their error during
    Andrew> testing. Better to raise an exception immediately if we know the
    Andrew> format is invalid.

I can live with that.  I would propose then that escape_char default to
something reasonable, not None.

    Andrew> This is an argument I have over and over - I believe it's nearly
    Andrew> always better to push errors back towards their source. In spite
    Andrew> of how it sounds, this isn't really at odds with "be liberal in
    Andrew> what you accept, be strict in what you generate".

If I cave on this, they you have to cave on None. ;-)

    >> * Files have to be opened in binary mode (we can check the mode
    >> attribute I believe) so we can do the right thing with line
    >> terminators.

    Andrew> We need to be a little careful when using uncommon interfaces on
    Andrew> the file class, because file-like classes may not have
    Andrew> implemented them (for example, StringIO doesn't have the mode
    Andrew> attribute).

Correct.  That occurred to me as well.  Do we just punt if hasattr(fileobj,
"mode") returns False?

    >> * Unicode.  I think we punt on this for now and just pretend that
    >> passing codecs.open(csvfile, mode, encoding) is sufficient.  I'm sure
    >> Martin von Löwis will let us know if it isn't. ;-) Dave said, "The low
    >> level parser (C code) is probably going to need to handle unicode."
    >> Let's wait and see how well codecs.open() works for us.

    Andrew> I'm almost 100% certain the C code will need work. But it should
    Andrew> the sort of work that can be done without disturbing the
    Andrew> interface too much?

"Handle Unicode" probably doesn't mean messing with encoding/decoding issues
though.  Let the user deal with them.

    Andrew> I haven't investigated how the official python test harness
    Andrew> works - it predates pyunit.

Most new tests are written using unittest (nee PyUnit) and many existing
tests are getting converted.  If we use the core test framework for as
much as we can, our unit tests will just move cleanly from the sandbox to
Lib/test/. 

Now to see about Mailman 2.1...

Skip