works in cases where the second two break
Text::xSV is an excellent module and handles more than Text::CSV but I wish you and dragonchild would quit spreading FUD about Text::CSV_XS. It has an much uglier interface than xSV and xSV does things not related to the actual parsing that CSV_XS does not do (and likewise Text::CSV_XS does non-parsing things that xSV does not). But when it comes to actually parsing CSV, the two modules are equivaqlent in what they can handle except for a few very unusual edge cases that CSV_XS handles that xSV does not. If you can find some text that works with xSV and does not work with CSV_XS, post it. Otherwise, refer to Benchmark comparison of Text::xSV and Text::CSV_XS and Comparison of the parsing features of CSV (and xSV) modules. If you like Text::xSV, great, recommend it to everyone on the planet (I often do), but there's no need to denigrate other modules because you've found one you like.
| [reply] |
There is actually one edge parsing case that Text::xSV handles differently than Text::CSV_XS where I think that Text::xSV's behaviour is more convenient. (There being no spec, it is impossible to say which is right.) In Text::xSV if you have ,, the embedded field is going to be undef, while if you have ,"", the embedded field is an empty string. (This distinction is drawn on writing as well.) Both of those come out as an empty string in Text::CSV_XS.
This behaviour was deliberately chosen to match how Microsoft tools export/import data. Access will turn ,, into a NULL and ,"", into an empty string, and will export them that way as well. Or at least that was how it worked when I last used Access. I don't think that you can draw this distinction in Text::CSV_XS.
Other than that, I believe that the two should have identical capabilities with default settings. But Text::CSV_XS has increased flexibility for changing how it handles parsing (eg changing quote character, delimiter, etc), and Text::xSV has increased flexibility for changing how you can access/manipulate data on the fly (aliases, computed fields).
| [reply] |
| [reply] |
jZed,
...but I wish you and dragonchild would quit spreading FUD about Text::CSV_XS.
I take offense to that. I only said I believed Text::CSV_xSV worked in cases where the other two did not. The focus was on the the use of the test suites anyway.
And what FUD exactly? Besides this thread, I have mentioned Text::xSV two other times and neither was condemning the other modules.
This post has been changed to reflect real information and not perceived information. I recognize jZed's point about spreading rumors which is why I didn't state my beliefs as being facts
| [reply] |
update Limbic-Region and I have said this to each other in /msgs but it bears public repeating - we're not trying to attck each other here and I for one apologize if it appears that I am.
update2 (after L~R's update to his node) Again, I apologize for accusing you of spreading FUD. I do believe what you said is FUD, but that doesn't mean that it was your intention to spread it. I also think your suggestion to the OP to use the test suites of the other modules was an excellent suggestion.
L~R I quoted the part of your text I objected to which was the part where you said that Text::xSV works in cases where Text::CSV_XS breaks. If you have evidence to support that claim, please present it. If you do not have evidence, please stop claiming it. Text::xSV is without a doubt, the best pure perl CSV parser around. It has the best interface of any CSV parser. But neither of those facts adds up to it being either faster than or better at edge cases than the C-based Text::CSV_XS. Again, I have no problem with you recommending Text::xSV, I also recommend it when appropriate. I do have a problem with you making claims about other modules without evidence to back it up.
| [reply] |