[Csv] Module question...

Cliff Wells LogiplexSoftware at earthlink.net
Thu Jan 30 20:58:25 CET 2003


On Wed, 2003-01-29 at 23:33, Andrew McNamara wrote:

> >> What was the rational for using files, rather making the user do their
> >> own readline(), etc?
> >
> >I'll try and summarize, if this is too simplistic or incorrect I'm sure
> >someone will speak up :)

> >One other possibility would be for the parser to only deal with one row at a
> >time, leaving it up to the user code to feed the parser the row strings. But
> >given the various possible line endings for a row of data and the fact that
> >a column of a row may contain a line ending, not to mention all the other
> >escape character issues we've discussed, this would be error-prone.
> 
> This is the way the Object Craft module has worked - it works well enough,
> and the universal end-of-line stuff in 2.3 makes it more seamless. Not
> saying I'm wedded to this scheme, but I'd just like to have clear why
> we've chosen one over the other.

It simplifies use for the programmer not to have to feed one line at a
time to the parser.  If the programmer needs to generate data one line
at a time, they can pass a pipe and feed data into that.

> I'm trying to think of an example where operating on a file-like object
> would be too restricting, and I can't - oh, here's one: what if you
> wanted to do some pre-processing on the data (say it was uuencoded)?

Then they can uudecode it, write it to a temp file and pass that instead
of the original.  I think the file-like object is the best compromise
between ease-of-use and flexibility.

> >The solution was to simply accept a file-like object and let the parser do
> >the interpretation of a record. By having the parser present an iterable
> >interface, the user code still gets the convenience of processing per row if
> >needed or if no processing is desired a result list can easily be obtained.
> >
> >This should provide the most flexibility while still being easy to use.

Hey, that's what I was thinking <wink>

> Should the object just be defined as an iteratable, and leave closing,
> etc, up to the user of the module? One downside of this is you can't
> rewind an iterator, so things like the sniffer would be SOL. We can't
> ensure that the passed file is rewindable either. Hmmm.

-1.  If it isn't sniffable, I'd end up having to write another CSV
parser to support the features DSV currently has.

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



More information about the Csv mailing list