Re: [cclib-devel] C bridge and changes to the progress updater

[Noel O'B. <bao...@gm...>]

On 9 February 2013 16:53, Adam Tenderholt <ate...@gm...> wrote:
> And here I thought when you extended Avogadro to parse a file with cclib,
> Avogadro had a python interpreter built in.

That's a good point. :-) I guess I thought it just happened by magic.

> It's actually calling the system
> Python and its installed packages? Well, it's possible to actually imbed an
> interpreter, load modules, and play around with Python objects
> (http://docs.python.org/2/extending/embedding.html). The API has a bit of a
> learning curve, so I figure if cclib provided functions that took care of
> most use cases, others might find it useful.
>
> The C-functions don't really impact the Python source (except for the
> callback function changes I've already made). But since I'm still working on
> the C-functions, I'm ok with those going into a separate branch (or the
> website).
>
> As far as the callback changes I've made, do you also want those in a
> separate branch? Or can they go in trunk for the 1.1 release? It involved
> only a handful of changes to logfileparser.py and the progress classes, and
> I think it's ready to go out with the next release.

The issue is just the fact that the API is changing in a way that is
not backwards compatible. If software that previously worked with
cclib will now fail to work, we need to renumber the release to 2.x. I
know that it may only require a small change to the user's code, but
the API numbering is an implicit contract with the user, and it's
understood as such by users and the Linux distros. If you can figure
out a way that preserves the old behaviour while extending it to the
new improved way, then it's not a problem and can go in trunk and into
the next release. But to be honest, we can do a 2.x in the next few
months, I'm not suggesting postponing it indefinitely.

Another thing I was wondering about is whether your C code is going to
be specific to Python 2? It would be nice to start targeting Python 3.
I know I've mentioned this before, but I really think we need to get
onto Python 3 at this point, and it might be better to make the change
now (i.e. right after the release) if you are going to be writing C
code. The Python 3 branch in svn is in good shape, if a year or so out
of date, but it wouldn't take me long to sort it out.

- Noel