Right, there are two things we need to do here; the core implementation (what's called _csv in CPython) and the hooks to Jython. It looks like Paul got pretty close on the first, and just needed to implement the module aspects. But this has gotten much easier with the new support for annotations in exposing, as I have personally found.
Re pulling in jars: 10K for a robust, well-used implementation seems to be a pretty good deal. But since Paul has dialect support apparently passing unit tests, it makes more sense to start with that, since this is the one piece that might be difficult to get right with a third-party package.
On Feb 12, 2008 12:51 PM, Jim Baker <firstname.lastname@example.org> wrote:I wouldn't go so far as to say a variety. I think we're only
> The only problems I would see are supporting csv's dialect options, but
> other than that, it sounds good, and certainly the strategy I would choose,
> including the choice of library (opencsv).
> Re that jar, we are already planning on packaging a variety of jars into
> Jython 2.5 via jar jar links, so that presumably could be done too with
including two: antlr and asm. Since those are made to be embedded in
this fashion and tiny as well, I'm not too worried about them. In
general, I'm really leery of including jars in Jython because they'll
almost certainly contain functionality we aren't using and I want to
keep Jython's core as small as possible to make it an easy decision
for users to embed it.