* separated values
Magnus Lie Hetland
mlh at vier.idi.ntnu.no
Tue Jan 15 22:16:29 CET 2002
In article <3dhepnmjir.fsf at ute.mems-exchange.org>, unknown wrote:
>On the other hand, arguments for adding it are:
>* A lot of people seem to need this.
>* Getting the code correct in the face of quoted fields and escaped "
> characters isn't trivial.
>I think I've seen questions about CSV often enough to be sick of them,
>so it seems likely that CSV is worth adding.
Exactly. Depending on the implementation, it's not going to be much of
a bloat either; this isn't exactly code-intensive.
I'm not sure which version one should use, though... I *do* believe it
is possible to formulate a definition of CSV which satisfies all
available versions, and which can be called "standard". The question
is which ones of the available modules support it, in addition to
performance, of course. Dave Cole's version seems to have high
performance, but I'm a bit worried that it doesn't seem to allow line
breaks inside quoted fields (which I believe some programs may
produce). Also, its insistence on having a field separator directly
after a closing quote may be correct, but perhaps allowing whitespace
before and after the separator had been more flexible?
Anyway... I agree that an "extra battery pack" and/or a package
repository would be a good thing. And, yes the question *is* "where do
we draw the line". I think csv falls within reasonable boundary lines
delineating the standard library. Others may disagree on this, but I
don't think arguments of the form "where will it all end" are really
BTW: If we can build an "extra fat" version of Python, why not also an
"extra lean" version? Then the standard version can have a copious
library, and those who dislike big downloads or whatever can use the
lean version... (It's all a matter of labelling, I guess :)
Magnus Lie Hetland The Anygui Project
More information about the Python-list