[SciPy-dev] Re: Open Office

eric jones eric at enthought.com
Fri Aug 2 15:37:06 CDT 2002


Hey Mark,

Thanks for the pointer to the OO project.

In general, I like to keep as much code at the Python level as possible.
Adding a dependency on a big honking library that handles many things in
C++ that are easily handled in Python makes for slower development and
more difficult builds.

Joining the efforts obviously has benefits, but I expect the needs of
the communities are not entirely coincident (business vs. scientific
plotting).  If building a solid plotting framework was a huge job
(multiple person years), then working to share the effort would be well
worth it.  But, building a solid plotting framework is what I'd consider
a "medium sized" job -- about one person year to build a robust python
API that is easy for others to extend.  In this sort of project, putting
up with the C++ hassles and the sub-set of 6.7 millions lines that we
would need is a large price to pay.  To top things off, most of the plot
architecture stuff falls in the category of things that Python does
really really well.

Chaco is already reasonably far along with the low level API, and Dave
Morrill has a first cut at a very impressive high level API working.
Dave's code isn't in CVS yet because it is wxPython specific, so you'll
have to take my word for it for now.  He started from plt, but I think
only a few of the axis layout algorithms survived his re-write.  Dave's
current code is an intermediate step towards the final Chaco
implementation, but, as an intermediate step, it is very far along.  We
will start re-working/integrating this work into Chaco in the 2nd half
of August.  

Dave's high level API is currently 6000-7000 lines of pure Python.
Chaco's low level API is another few thousand lines.  They'll both grow,
but I doubt they'll more than triple in the final version and even that
would be surprising.  This would mean 30000 lines of mostly Python code
(hmm I'm leaving out the freetype C source code in this count).  This is
probably 1/10  the size of the code base if we used OO.

All this to say, the plan is to stick as close as possible to a pure
python library with C/C++ used only in critical sections.  Thanks for
the pointer to the OO effort though.  It is always good to have other
APIs as examples -- especially as we move into designing the higher
level portion of Chaco.  And, I'll be very interested in playing with OO
when a solid Python API is around for it.  I just don't want to be the
one debugging it for the sake of a plotting package. :)

see ya,
eric


> -----Original Message-----
> From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of Mark Evans
> Sent: Friday, August 02, 2002 2:52 PM
> To: scipy-dev at scipy.net
> Subject: [SciPy-dev] Re: Open Office
> 
> > This sounds really good but OO.o is a huge project.  I'm not sure it
> > is going to be easy to simply join without investing a huge amount
of
> > time on this.  I also heard that building OO.o is a big pain.  I'm
not
> > sure what the others think of this.
> >
> > cheers,
> > prabhu
> 
> Those are fair points but don't you think joining OO would be easier
> than constructing an entire chart API from scratch, all alone?
> 
> I don't think SciPy would have to build all of OO, just the UNO
> interface layer.  Someone has already done a Python wrapper for UNO.
> UNO components are like COM components (and in fact there exists a
> COM/UNO bridge).
> 
> Regarding building OO I think some pain is natural with a 6.7 million
> line cross-platform package, although these comments may invalidate
> some previous criticisms --
> 
> http://udk.openoffice.org/common/man/uno.html
> 
> "StarOffice mainly uses the C++ -in-process functionality of UNO.
> Before UNO, the StarOffice development suffered very much from
> incompatible changes (e.g., adding a new virtual method or a new
> member to a class) in one of the base libraries. This forced a
> complete rebuild of the product, which roughly consumed 2 days and was
> done only once a week. These incompatible updates were be reduced
> considerably by using UNO, and as a result the whole work became more
> efficient. Please have a look at this document, Uno_the_Idea, for a
> more complete explanation."
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev




More information about the Scipy-dev mailing list