The Week 5

As scheduled, we met again last Thursday i.e on 11th June. When I entered in the conference call, Andreas and Matthias were already there and discussing something. We soon started our discussion. This time, I was required to implement all the necessary meta-data classes to completely have support for annotation in COBRApy. As we discussed earlier to have these meta-data classes behave exactly like "dictionary" of python, basically doing "Duck Typing", I thought it would be better if I inherit these classes from "dict" and "list" themselves, and override their corresponding methods of setting values by putting the restrictions which we want to have on the annotations. So I made the following classes:

• CVTerm class, by inheriting from dict, which will handle the external resources linked to that component,
• History class, again by inheriting from dict, that will keep a track of the History of that component,
• ListofKeyValuePair class, by inheriting from the list, that will support the key-value pairs introduced in fba-v3 package, and
• the main MetaData class, by inheriting from dict, that will keep objects of each of the above-defined classes to completely define the annotation component of the model.

Almost all of the above classes also had inner classes to define the internal structure. Though everything was looking fine, these classes suffered from a serious issue. Inheriting the basic data structures of python i.e., dict and list, is not a right thing to do. I can't explain all the details here about why inheriting from these classes is not right, but to give you some light, we can't just override a few main methods of these classes where getting and setting of the values is happening because many other methods of these classes do this thing quite differently, and it will be very painful for us to make them behave in a right way. Thanks to Matthias for pointing out this thing, it is surely an important piece of information for python developers to know. If you want to dig deeper, go through this blog, it explains all the pros and cons, and also the alternative which we should use to make our custom data structure behave like dict and list with our own defined restrictions. Abstract Base Classes, from the "collection" module, are what we should go with to solve our problem. This module provides some basic abstract classes, which we should inherit to define our own data structures. Fortunately, almost similar methods are required to override for these classes, which I had overridden from "dict" and "list". So the code which I wrote required only a few changes, like inheriting from "MutableMapping" in place of "dict" and "MutableSequence" in place of "list" and addition of a few more methods.

Up until now, I was thinking that we are going to have a completely new format for the annotation part, but Matthias suggested a better idea. He suggested to store the information about the external resources in the CVTerm class, and one can get them whenever they want in this new format via different syntax, but also let the users get information out from these classes using the old syntax also. Now, though, the old syntax can't handle all the resource annotation, we would parse only those which can be parsed. This won't even break the old test cases, and those who still want to use the old formats will be free to use it. I am currently working on this thing, and if we could successfully achieve it, it will be very helpful. This is an important task to achieve this week, along with the implementation of notes feature in COBRApy. Currently, COBRApy only extracts key-value pairs, if present, out of the notes string, and leave the remaining information. This is one source of information loss, and we shall cover it this week. With the completion of this thing, we would have a complete lossless conversion for the meta-data part.

That's all for this week. I hope you are enjoying it!