[Biocorba-l] Biocorba-0.2.0 - A proposal

Matthew Pocock mrp@sanger.ac.uk
Fri, 10 Nov 2000 12:17:05 +0000


Brad Chapman wrote:

> Hmmm, I guess I don't understand what the switch does exactly
> then. Does it:
>
> a. Make the sub-SeqFeatures available through the sub_SeqFeatures()
> (ie. if you don't have a True for sub_seqfeatures sub_SeqFeatures()
> will return nothing).
>
> b. Flatten all of the features so that they are all top level and
> there are no sub_SeqFeatures()
>
> I thought that it meant a. originally, but now I am really
> confused... Anyways, I would like to always see the behavior of having
> sub_SeqFeatures() and just drop out the boolean value to avoid having
> to deal with it (ie. so I won't get so confused :-).
>

The idea is that features may contain child features. For example, you may have
set up your server so that it serves transcript features with exon child
features, or promoter region features with tf-binding-site child features. If you
ask the sequence for all features without the recurese, you would be able to loop
over each transcript or promoter region. If you are interested in any particular
one, then you can ask it for an iterator over its children, but you are not
required to look inside it. If you ask the sequence for all features with
recursion, then you will get back an iterator over all features, child features,
child-child features... Basicaly, the recurse flag lets you chose the granularity
that you pull back, rather than forcing you to always get everything. This is, I
think, a good thing to chose, and certainly means that clients can be more polite
about how much stuff they pull over. If the recurse flag was dropped, then the
apropreate default would be to return all top-level features, and for the client
to look inside them if it wants.

Matthew

> Brad
>
> _______________________________________________
> Biocorba-l mailing list
> Biocorba-l@biocorba.org
> http://www.biocorba.org/mailman/listinfo/biocorba-l