bugzilla-daemon | 2 Sep 15:06 2008

[Bug 2543] Bio.Nexus.Trees can't handle named ancestors

http://bugzilla.open-bio.org/show_bug.cgi?id=2543

------- Comment #3 from biopython-bugzilla <at> maubp.freeserve.co.uk  2008-09-02 09:06 EST -------
Hi Frank,

Did you get a chance to look at that code for named ancestors?

Thanks

Peter

--

-- 
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon | 2 Sep 16:05 2008

[Bug 2543] Bio.Nexus.Trees can't handle named ancestors

http://bugzilla.open-bio.org/show_bug.cgi?id=2543

------- Comment #4 from cymon.cox <at> gmail.com  2008-09-02 10:05 EST -------
Hi Peter,

> Can I ask if you've actually come across trees with names ancestor nodes in
> "real life"?  That would make this bug more important.  If so, the name of the
> tool would be interesting,

P4 (http://code.google.com/p/p4-phylogenetics/) is the only one I'm aware of.

As Frank implies the labels at nodes arent necessarily names of ancestors but
rather are just labels that can be any text. In P4 they are they are just an
string attribute of the node object. P4 uses them primarily to aid tree
drawing. Support indices in phylogenetics are properties of branches and this
is fine in a unrooted tree context. But most systematists want to orientate the
tree, ie. root it informally, and refer to a particular node having the support
value of its subtending branch. Its therefore useful to transfer the branch
support values to node labels before drawing the tree.

> an example tree file would be great to add to
> Biopython as a test case.

How about this:
             +--------------3:t9
      +------2:B
      |      |     +----------------5:t8
      |      +-----4:C
+-----1:A          +---------------6:t4
|     |
(Continue reading)

bugzilla-daemon | 2 Sep 17:44 2008

[Bug 2543] Bio.Nexus.Trees can't handle named ancestors

http://bugzilla.open-bio.org/show_bug.cgi?id=2543

------- Comment #5 from fkauff <at> biologie.uni-kl.de  2008-09-02 11:44 EST -------
(In reply to comment #3)

Hi Peter,

haven't done anything yet. The previously mentioned code works different
(assigning values to nodes within a [&...] comment), rather than names to
nodes.

Assigning names to nodes can be very useful, but as Cymon mention, P4 seems to
be the only program that can handle them.
In my opinion, naming nodes is a feature, and I would not regard the lack of
this feature as a bug.
But I'll have a look at the code and see how easy this can be changed. It would
actually be nice if P4 and Bio.Nexus, both being python programs, could read
each other's trees.

(Hi Cymon :-) )

Frank

> Hi Frank,
> 
> Did you get a chance to look at that code for named ancestors?
> 
> Thanks
> 
> Peter
(Continue reading)

Peter | 2 Sep 17:49 2008
Picon
Picon

Preparing for Biopython 1.48

Dear all,

Is there anything we need to address before starting to prepare Biopython 1.48?

This is likely to be the final Numeric only release of Biopython, with
the following release hopefully supporting both Numeric and numpy in
some way.

(As an aside, once we support numpy, having scipy as an optional
dependency for the statistics Tiago wanted to use in Bio.PopGen does
seem less onerous.)

Regarding potentially deprecating Bio.Mindy and Martel, I propose we
do this in the following release (i.e. after Biopython 1.48).  We can
then drop the mxTextTools dependency completely.

While I would like to address some of the enhancements (esp Bug 2530)
these can wait.  Ignoring the enhancements, there are several "small"
issues on bugzilla that could be dealt with, but nothing that I think
warrants delaying the release.

One question: Currently Bio.SeqIO in CVS has partial support for
writing GenBank files (basically the sequence and minimal annotation -
no references, no features).  I don't want to rush something out
without proper testing, so do people think it would be better to ship
with this partial support, or temporarily disable it (a one line
change in Bio/SeqIO/__init__.py to the _FormatToWriter dictionary, and
probably refreshing the expected unit test output).

Comments and suggestions welcome!
(Continue reading)

Tiago Antão | 2 Sep 20:25 2008
Picon

Re: Preparing for Biopython 1.48

Hi All,

On Tue, Sep 2, 2008 at 4:49 PM, Peter <biopython <at> maubp.freeserve.co.uk>wrote:

> (As an aside, once we support numpy, having scipy as an optional
> dependency for the statistics Tiago wanted to use in Bio.PopGen does
> seem less onerous.)
>

First, my apologies for not reporting back from BOSC,but I was in a
conference/professional visit spree for the last 3 months, returned last
most. Basically it was not OK: I arrived there from a previous conference
and did the presentation without little sleep, it was probably the sloppiest
presentation in my whole life. My sincere apologies.

On a better front, I have a lot of new content for Bio.PopGen, a few
remarks:
1. No documentation and testing done, so I will skip adding content to 1.48.
But I will surely add to 1.49.
2. None of the new content relies on scipy (as there was no agreement on
that), but being able to use scipy would make things much easier. Most of
anything that can be called "population genetics" is nothing more than
statistics (statistics were invented because of population genetics). So a
change in policy would be welcomed (and would make Bio.PopGen really useful
for a wide audience - currently it has only niche users).

In another front, we published a paper using content from Bio.PopGen 1.44
http://www.biomedcentral.com/1471-2105/9/323

Regards,
(Continue reading)

Peter | 2 Sep 21:05 2008
Picon
Picon

Re: Preparing for Biopython 1.48

Tiago wrote:
>> First, my apologies for not reporting back from BOSC,but I was in a
>> conference/professional visit spree for the last 3 months, returned last
>> most. Basically it was not OK: I arrived there from a previous conference
>> and did the presentation without little sleep, it was probably the
>> sloppiest presentation in my whole life. My sincere apologies.

I hardly dared ask how you felt at the end of your almost round the
world trip ;)

Jared wrote:
> Despite Tiago's self-criticism I thought his BOSC presentation was fine and
> up to par with the rest of them.
>
> jared

That sounds much more positive :)

This reminds me that I could/should make a PDF version of the BOSC
2008 slides to go online here:
http://biopython.org/wiki/Documentation#Presentations

>> On a better front, I have a lot of new content for Bio.PopGen, a few
>> remarks:
>> 1. No documentation and testing done, so I will skip adding content to
>> 1.48.  But I will surely add to 1.49.

That sounds sensible, and another reason to get Biopython 1.48 out
soon.  Depending how my day goes tomorrow, I could try then.

(Continue reading)

Jared Flatow | 2 Sep 20:42 2008

Re: Preparing for Biopython 1.48

Despite Tiago's self-criticism I thought his BOSC presentation was  
fine and up to par with the rest of them.

jared

On Sep 2, 2008, at 1:25 PM, Tiago Antão wrote:

> Hi All,
>
> On Tue, Sep 2, 2008 at 4:49 PM, Peter  
> <biopython <at> maubp.freeserve.co.uk>wrote:
>
>> (As an aside, once we support numpy, having scipy as an optional
>> dependency for the statistics Tiago wanted to use in Bio.PopGen does
>> seem less onerous.)
>>
>
> First, my apologies for not reporting back from BOSC,but I was in a
> conference/professional visit spree for the last 3 months, returned  
> last
> most. Basically it was not OK: I arrived there from a previous  
> conference
> and did the presentation without little sleep, it was probably the  
> sloppiest
> presentation in my whole life. My sincere apologies.
>
> On a better front, I have a lot of new content for Bio.PopGen, a few
> remarks:
> 1. No documentation and testing done, so I will skip adding content  
> to 1.48.
(Continue reading)

Tiago Antão | 2 Sep 21:29 2008
Picon

Re: Preparing for Biopython 1.48

On Tue, Sep 2, 2008 at 8:05 PM, Peter <biopython <at> maubp.freeserve.co.uk>wrote:

> This reminds me that I could/should make a PDF version of the BOSC
> 2008 slides to go online here:
> http://biopython.org/wiki/Documentation#Presentations
>

http://www.slideshare.net/tiago/bosc-2008-biopython
Is there for a month, by I completely forgot to inform.

Tiago
bugzilla-daemon | 3 Sep 18:46 2008

[Bug 2578] New: The GenBank SeqRecord parser does not record module type or if circular

http://bugzilla.open-bio.org/show_bug.cgi?id=2578

           Summary: The GenBank SeqRecord parser does not record module type
                    or if circular
           Product: Biopython
           Version: 1.47
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Main Distribution
        AssignedTo: biopython-dev <at> biopython.org
        ReportedBy: biopython-bugzilla <at> maubp.freeserve.co.uk

Filing this bug after discussion on the mailing list, where the issue was
raised by Chris Lasher:
http://lists.open-bio.org/pipermail/biopython/2008-September/004474.html
http://lists.open-bio.org/pipermail/biopython/2008-September/004475.html
http://lists.open-bio.org/pipermail/biopython/2008-September/004476.html

The LOCUS line at the start of a GenBank record can record the molecule type
(DNA, RNA, mRNA, protein etc) and also if the sequence is linear or circular,
e.g.

LOCUS       NC_002678            7036071 bp    DNA     circular BCT 22-JUL-2008

Currently Bio.SeqIO (and Bio.GenBank.FeatureParser if called directly) do not
record these two bits of information in the SeqRecord.

(Continue reading)

bugzilla-daemon | 3 Sep 18:54 2008

[Bug 2578] The GenBank SeqRecord parser does not record module type or if circular

http://bugzilla.open-bio.org/show_bug.cgi?id=2578

------- Comment #1 from biopython-bugzilla <at> maubp.freeserve.co.uk  2008-09-03 12:54 EST -------
Note that after any change made to record this information, the preliminary
GenBank writing support for Bio.SeqIO should also be updated - see Bug 2294.

It would also be sensible to see how BioPerl, BioJava etc store this
information within BioSQL so that if possible we can do it the same way.  I'm
assuming this is just a case of picking the same text (term table key) for our
annotations dictionary key.

--

-- 
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Gmane