[Csv] CSV interface question

[Cliff Wells]

On Wed, 2003-01-29 at 09:41, Skip Montanaro wrote:
>     Cliff> Actually, there is a downside to using strings, as you will see
>     Cliff> if you look at the code I posted a little while ago.  By taking
>     Cliff> dialect as a string, it basically precludes the user rolling
>     Cliff> their own dialect except as keyword arguments.  After working on
>     Cliff> this, I'm inclined to have the programmer pass a class or other
>     Cliff> structure.
> 
> Don't forget we have the speedy Object Craft _csv engine sitting underneath
> the covers.  Under the assumption that all the actual processing goes on at
> that level, I see no particular reason dialect info needs to be anything
> other than a collection of keyword arguments.  

You've lost me, I'm afraid.  What I'm saying is that:

csvreader = reader(file("test_data/sfsample.csv", 'r'), dialect='excel')

isn't as flexible as

csvreader = reader(file("test_data/sfsample.csv", 'r'), dialect=excel)

where excel is either a pre-defined dictionary/class or a user-created
dictionary/class.  

As an aside, I prefer using a class as it allows for validating the
dialect settings from the dialect object itself (see the CSV.py I posted
earlier).

> I view csv.reader and
> csv.writer as factory functions which return functional readers and writers
> defined in _csv.c.  The Python level serves simply to paper over the
> low-level extension module.

That's what I see also (even though the CSV.py I posted earlier doesn't
exactly follow that convention).  I do think we need a pure Python
alternative to the C module, but both of them should be exposed via a
higher-level interface.  Unfortunately, I'm still not mentally linking
this with my earlier point =)

-- 
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308  (800) 735-0555 x308

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