[gt-users] extending python bindings

[Brent Pedersen]

On Thu, Nov 20, 2008 at 12:41 PM, Sascha Steinbiss
<steinbiss at zbh.uni-hamburg.de> wrote:
> 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.

ok. thanks sascha, i can wait, just figured i'd try my hand at ctypes
-- which seems mostly
straightforward.

>
>> 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)]
>

understood, i'll wait for your branch to be merged before i try too
much more tinkering. custom track stuff looks cool.

> 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.
>

i agree, but didnt know what to do. do you mean something like below?

class FeatureNode(GenomeNode):
    __init__(self, *args, **kwargs):
        if len(args) == 1: # node_ptr
               # init with pointer
        else:
             # init with python attrs


> 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).
>

ok.  and one more question,
in extended/genome_node.py, why dont you need to declare the args and
restype for:
gtlib.gt_genome_node_ref or  gtlib.gt_genome_node_delete?
i dont understand how that is working.

thanks again,
-brent


>> 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
>
> _______________________________________________
> gt-users mailing list
> gt-users at genometools.org
> http://genometools.org/mailman/listinfo/gt-users
>