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 2:09 PM, Charlie Groves <charlie.groves@...> wrote:
> On Feb 12, 2008 12:51 PM, Jim Baker <jbaker@...> wrote:
> > Dave,
> > 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
> > 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
> > opencsv.
> I wouldn't go so far as to say a variety. I think we're only
> 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.