Re: [cclib-devel] Separation of parsers and data

[Karol L. <kar...@kn...>]

On Wednesday 11 July 2007 11:56, Noel O'Boyle wrote:
> On 11/07/07, Adam Tenderholt <a-t...@st...> wrote:
> > Can you (again) describe what changes will be necessary?

There is a new class - cclibData (or whatever we rename it to). It contains 
the attribute lists and handles the checking of types in its own __setattr__ 
method - and should do everything concerned with data after it is parsed 
instead of Logfile.

The biggest change is that Logfile.parse() returns something, that is an 
instance of cclibData, which should hold the parsed attributes upen return. 
It is the biggest, because it changes the way cclib will be used. Now you 
need to write something like "data = ccopen(...).parse()" and data will hold 
the parsed data.

Changes are presently contained to logfileparser.py to make things clear and 
simple. However, it might be better to accomodate them in the parsers 
themselves later (that is, in the extract method) - currently attributes are 
set to Logfile as before and moved to the new cclibData object after the 
actual parsing (look at the new code). I don't know if that will raise any 
problems, but it has the potential :)

> > Will this happen in trunk, or in a separate branch?
> > How is this going to affect parsers that are being developed in a
> > different branch?
> > How long do you expect this to take?
>
> I think Karol's email of the 9th of this month actually has the
> changes as an attachment. I think they are pretty minimal.
>
> I would hope for it to be all done quick and nasty on the trunk within
> a single day or so, and then merged to the branches, and then
> completed for the parsers on the branches. We should start using
> svnmerge.py for the branches to make it easy to keep track of what has
> been merged, and in what direction.

Done. I had to add a few more things to the file I sent before to get things 
working. Seems to be OK, test statistics are unchanged.

Concerning Calculation Methods in cclib: they need to accept cclibData objects 
now. And a comment/idea: since cclibData objects are to hold cclib data in 
general, perhaps they should also contain the results of methods (MPA, etc.). 
It annoys me a little that after doing a population analysis I have a two 
objects, both containing data that concern the same calculation! On the other 
hand, other methods need multiple cclibData objects (CDA). Maybe a good 
alternative is to provide functions for some methods that add the method 
results to the same cclibData object passed to them, instead of creating a 
new object. I'm not sure if that is clear... do you have any comments?

-- 
written by Karol Langner
Thu Jul 12 02:30:47 EDT 2007