DSVWizard.py

[Dave Cole]

>>>>> "Cliff" == Cliff Wells <LogiplexSoftware at earthlink.net> writes:

Cliff> Okay.  So the default behavior would be to *not* treat the
Cliff> quotes as text qualifiers in the following:

Cliff> data, "data", data

Cliff> unless the user specifies otherwise.

I believe that is how Excel works.

>> One of the people we have done work for has some very nasty "CSV"
>> data to parse.  We have been trying to work out what to do to the
>> CSV module to handle some of the silly things he sees without
>> breaking the Excel compatibility.

Cliff> Having "variants" as Skip mentioned (and I think you did as
Cliff> well) would solve this.

Cliff> I'm also a bit curious as to the "Treat consecutive delimiters
Cliff> as one" option in Excel.  I had planned to add support for that
Cliff> in DSV but never got around to it.  Does csv have such an
Cliff> option?  Is this really ever useful?  I've never had anyone
Cliff> request that I enable that option in DSV, despite the fact that
Cliff> there's even a checkbox (disabled) for it in the GUI.

I suppose there is no reason why we could not allow people to invoke
variants like this;

        p = csv.parser(app='Excel', consecutive_delimiters=1)

The API could be as simple as

        def parser(**kwargs):
            app = kwargs.get('app', 'Excel')

Cliff> Actually, it's only the V part of CSV that's poorly defined
Cliff> <wink>.  Maybe CSV should stand for "comma separated
Cliff> vagueness".

LOL.

Cliff> Speaking of names, since Kevin is correct in that people will
Cliff> look for CSV since that's the common term, we could just define
Cliff> C to stand for "character" rather than "comma", since this will
Cliff> be a general-purpose importer.

Or use both.  As long as you use include "comma separated values" and
"character separated values" google will find it.

- Dave

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