[CSV] Re: First Cut at CSV PEP

[Dave Cole]

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

Dave> The point of the 'raw' dialect is to expose the full
Dave> capabilities of the raw parser.  Maybe we should use None rather
Dave> than 'raw'.

Skip> Nah, "raw" won't mean anything to anyone.  Make "excel2000" the
Skip> default.  The point of the dialect names is that they should
Skip> mean something to someone.  That generally means application
Skip> names, not something lile "raw".  I think it also means you only
Skip> have variants associated with applications which normally
Skip> provide few choices.  We can probably all come close to
Skip> specifying what the parameter settings are for "excel2000", but
Skip> what about "gnumeric"?  As I write this I'm looking at a
Skip> Gnumeric "Save As" wizard.  The user can choose line termination
Skip> (LF is the default), delimiter (comma is the default), quoting
Skip> style (automatic (default), always, never), and the quote
Skip> character (" is the default).  Even though the wizard presents
Skip> sensible defaults, I'm less enthusiastic about creating a
Skip> "gnumeric" variant, precisely because it won't necessarily mean
Skip> much.

Before we get too excited about setting dialect names in stone we
might want to start on the torture test.  It seems logical (to me)
that the first step in cataloguing dialects is to define the
classification tool.  We may find that many applications are faithful
clones of 'excel' (rather than 'excel2000', 'excel97', 'excel.net').

Cliff> I think it is an option to save as a TSV file (IIRC), which is
Cliff> the same as a CSV file, but with tabs.

Dave> Hmm...  What would be the best way to handle Excel TSV.  Maybe a
Dave> new dialect 'excel-tsv'?

Skip> Any of:

Skip>     reader = csv.reader(file("some.csv"),
Skip>                         variant="excel2000-tsv")

Are you suggesting that each dialect have a collection of variants?
This would mean you would have two layers of settings (is this a good
thing?)  The variant could just be a way of layering a set of options
over the options defined by a dialect.  I can see Andrew telling us to
KISS.

Dave> I am not saying that the wrapper should absolutely prevent
Dave> someone from using options not available in the application.  If
Dave> you want to break the dialect then maybe it should be a two step
Dave> process.

Dave> csvwriter = csv.writer(file("newnastiness.csv", "w"),
Dave>                        dialect='excel2000')
Dave> csvwriter.setparams(delimiter='"')

Skip> That seems cumbersome.  I think we have to give our users both
Skip> some credit (for brains) and some flexibility.  It seems
Skip> gratuitous (and unPythonic) to specify some parameters in the
Skip> constructor and some in a later method.

I have been convinced now that this is a bad idea.

Skip> All this dialect stuff will be handled at the Python level,
Skip> right?

Yes.  In my mind all that the extension module would be is an engine
with a set of configurable items.  No knowledge of dialects (or
variants) would be in the C code.

- Dave

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

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