[gt-users] extending python bindings

[Sascha Steinbiss]

Brent Pedersen wrote:
> hi,

Hi Brent,

> are there plans to expand the bindings to provide more granular access
> to the library, and or will you accept patches that do so?

Yes, we are currently working on the FeatureNode API to make it ready to 
get finally exposed to scripting languages (maybe Gordon can further 
comment on this). If you can wait a little bit longer, we will have them 
ready. If you want to contribute, feel free to do so. I could then 
incorporate code from your patches into the final bindings. I am still 
in the process of cleaning out some bugs before moving on to this, but I 
will inform you when everything is ready.

> http://pastebin.ca/raw/1261903
> i'm not sure how to handle the strand enum with ctypes. and i'm not
> sure of the relation between the _api.h files and
> the corresponding .h files...
> any help on that or comments on the code are welcome.

In the Block class of my 'newiface' branch on github (where my latest 
code is stored), I use a list strandchars = ['+','-','.'], into which I 
then index to handle strand assignment like this:

   def set_strand(self, strand):
     if not strand in strandchars:
       gterror("Invalid strand '%s' -- must be one of %s" \
                  % (strand, strandchars))
     gtlib.gt_block_set_strand(self.block, strandchars.index(strand))

   def get_strand(self):
     return strandchars[gtlib.gt_block_get_strand(self.block)]

The _api.h files contain functions which should be public for anyone who 
includes the "genometools.h" headers and/or uses the bindings, while the 
.h files contain functions which are only needed in the internal C 
implementation. For the bindings, only the functions in the _api.h files 
need to be handled (unless of course, a new class should be exposed).

The code looks ok, though the introduction of another FeatureNode class 
may be confusing... maybe one could think about extending the current 
class to allow for creating new nodes on the C side in addition to 
wrapping pointers.

IIRC, using FeatureNode instead of c_void_p in the secont argument of 
the gtlib.gt_feature_node_add_child.argtypes would give additional type 
checking, so I would prefer that. Of course, the add_child() method 
would then call gtlib.gt_feature_node_add_child(self.gn, child).

> thanks,
> -brent

You're very welcome. Best regards,
Sascha

-- 
Sascha Steinbiss
Zentrum für Bioinformatik
Universität Hamburg
Bundesstr. 43
20146 Hamburg
Germany

Email:  steinbiss at zbh.uni-hamburg.de
URL:    http://www.zbh.uni-hamburg.de/steinbiss
Phone:  +49 (40) 42838 7322
FAX:    +49 (40) 42838 7312