[Csv] CSV interface question

Dave Cole djc at object-craft.com.au
Thu Jan 30 11:06:23 CET 2003


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

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
Cliff> on this, I'm inclined to have the programmer pass a class or
Cliff> other structure.

Skip> Don't forget we have the speedy Object Craft _csv engine sitting
Skip> underneath the covers.  Under the assumption that all the actual
Skip> processing goes on at that level, I see no particular reason
Skip> dialect info needs to be anything other than a collection of
Skip> keyword arguments.  I view csv.reader and csv.writer as factory
Skip> functions which return functional readers and writers defined in
Skip> _csv.c.  The Python level serves simply to paper over the
Skip> low-level extension module.

I have been going through the messages again to see if I can build up
a TODO list.

I missed something on the first reading of this message.

In the current version of the code sitting in the sandbox the reader
factory is actually a class:

    class reader(OCcvs):
        def __init__(self, fileobj, dialect = 'excel2000', **options):
            self.fileobj = fileobj
            OCcvs.__init__(self, dialect, **options)

        def __iter__(self):
            return self

        def next(self):
            while 1:
                fields = self.parser.parse(self.fileobj.next())
                if fields:
                    return fields

You message above talks about the _csv parser exposing the iterator
interface, not the Python layer.  I wonder how much of a measurable
performance difference there would be by leaving the code as is.

- Dave

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



More information about the Csv mailing list