[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