headers
Wibowo Arindrarto | 1 May 2012 16:52
Picon
Gravatar

Re: [Biopython] Google Summer of Code Project: SearchIO in Biopython

On Mon, Apr 30, 2012 at 12:57, Peter Cock <p.j.a.cock <at> googlemail.com> wrote:
> On Mon, Apr 30, 2012 at 11:08 AM, Wibowo Arindrarto
> <w.arindrarto <at> gmail.com> wrote:
>>
>> I'm thinking of using the Search object as the object returned by
>> SearchIO.parse or SearchIO.read. That way, we can store attributes
>> common to the different search queries in it. For example:
>>
>>>>> search  = SearchIO.parse('blast_result.xml', 'blast-xml')
>>>>> search.format
>> 'blast-xml'
>>>>> search.algorithm
>> 'blastx'
>>>>> search.version
>> '2.2.26+'
>>>>> search.database
>> 'refseq_protein'
>>>>> search.results
>> <generator object results at ....>
>>
>> And iteration over the results would be done like this (for example):
>>>>> for result in search.results:
>> ... print result.query, print len(result)
>>
>> Additionaly, we can also define __iter__ and next for Search so we can
>> just do the following:
>>>>> for result in search:
>> ... print result.query, print len(result)
>>
>> What do you think?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wibowo Arindrarto | 2 May 2012 10:17
Picon
Gravatar

HMMER (+ BLAT) wrappers

Hi everyone,

The past week I've been trying to generate some test cases for BLAST,
HMMER, et al. I was writing some short scripts to automate the test
case generation, when I realized that Biopython doesn't have wrappers
for HMMER and BLAT, so I decided to write them. The code is here:
https://github.com/bow/gsoc/blob/master/hmmer/_HMMER.py and here:
https://github.com/bow/gsoc/blob/master/blat/_BLAT.py.

If it is of general interest to Biopython, I'd love to submit a pull
request for these wrappers. They were primarily written for test case
generation, but I imagine they won't require that many tweaks to make
it suitable for inclusion in Biopython. However, before I can do that,
there are some issues that I think needs to be discussed:

1. Where should the wrappers be put? I noticed that different wrappers
are located in different directories according to their 'theme' (e.g.
BLAST wrappers in Bio.Blast.Applications and ClustalW wrapper in
Bio.Align.Applications). For the HMMER wrapper, should it be put
inside Bio.Motif.Applications? For the BLAT wrapper, should I create a
new Bio.Blat folder just for it? Yesterday I thought maybe it would be
easier if all application wrappers are put inside the same directory
(e.g. all in Bio.Applications), so maybe that's a viable option for
future releases?

2. How should shared options among slightly different programs be
handled? We can rely on creating abstract subclasses for them, but I
find it easier to simply create lists and then combine them in the
different programs. The current HMMER wrapper employs both of these
approaches, but I think it needs to stick to just one approach to make
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Mitchell | 2 May 2012 16:50
Picon

Re: HMMER (+ BLAT) wrappers

Hey Bow,

I think it would be better to have an option to send the query to the local
server should one be running as opposed to wrapping a gfServer that would
be local for the duration of a given python process.  This would allow for
cases where someone has their BLAT queries split up in a script and not
incur the loading time for the database multiple times.  The
gfServer/gfQuery setup is also rather a pain to use from my experience
(it's all relative paths).  I also think using the -pslx output would be a
better default since -psl doesn't provide you with the sequence alignments.

Chris

On Wed, May 2, 2012 at 4:17 AM, Wibowo Arindrarto <w.arindrarto <at> gmail.com>wrote:

> Hi everyone,
>
> The past week I've been trying to generate some test cases for BLAST,
> HMMER, et al. I was writing some short scripts to automate the test
> case generation, when I realized that Biopython doesn't have wrappers
> for HMMER and BLAT, so I decided to write them. The code is here:
> https://github.com/bow/gsoc/blob/master/hmmer/_HMMER.py and here:
> https://github.com/bow/gsoc/blob/master/blat/_BLAT.py.
>
> If it is of general interest to Biopython, I'd love to submit a pull
> request for these wrappers. They were primarily written for test case
> generation, but I imagine they won't require that many tweaks to make
> it suitable for inclusion in Biopython. However, before I can do that,
> there are some issues that I think needs to be discussed:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wibowo Arindrarto | 2 May 2012 17:21
Picon
Gravatar

Re: HMMER (+ BLAT) wrappers

On Wed, May 2, 2012 at 4:50 PM, Chris Mitchell <chris.mit7 <at> gmail.com> wrote:
> Hey Bow,
>
> I think it would be better to have an option to send the query to the local
> server should one be running as opposed to wrapping a gfServer that would be
> local for the duration of a given python process.  This would allow for
> cases where someone has their BLAT queries split up in a script and not
> incur the loading time for the database multiple times.  The
> gfServer/gfQuery setup is also rather a pain to use from my experience (it's
> all relative paths).  I also think using the -pslx output would be a better
> default since -psl doesn't provide you with the sequence alignments.
>
> Chris
>

Hi Chris,

You are talking about 'gfServer query ...' right? That does make
gfServer usable enough to be wrapped. Thanks for pointing that out ~ I
overlooked that gfServer can also do queries. I admit that the current
BLAT wrapper is very minimum, but like I said, it shouldn't take that
much time to write wrappers for the rest of the executables in the
suite :).

As for the file format, I actually prefer leaving the options as it is
(i.e. the program's default) to keep surprises minimum to users (even
though I agree that the pslx output is more informative).

Bow
(Continue reading)

Permalink | Reply | 0 comments |
headers
redmine | 2 May 2012 21:04

[Biopython - Bug #3348] (New) Documentation error


Issue #3348 has been reported by Patrick P.

----------------------------------------
Bug #3348: Documentation error
https://redmine.open-bio.org/issues/3348

Author: Patrick P
Status: New
Priority: Normal
Assignee: 
Category: 
Target version: 
URL: 

 4.3.3  Sequence

 [...] For example consider a (short) gene sequence with location 5:18 on the reverse strand, which in
GenBank/EMBL notation using 1-based counting would be complement(4..18), like this: [...]

-------------------------
<pre>
                                                                         vvv
                                                                          v
 ---> in GenBank/EMBL notation using 1-based counting would be complement(6..18)
                                                                          ^
                                                                         ^^^
</pre>

----------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Cock | 3 May 2012 19:50
Gravatar

Re: SeqIO circular

On Saturday, April 28, 2012, Matthias Bernt wrote:

> Dear developers,
>
> I would like to suggest a quick "fix" for the problem. Currently the
> parser just returns true per default for the circular property. This
> is a wrong piece of information for all circular sequences.
> Furthermore its not possible to detect if the parser did return true
> because it is its default value or if its really from the data. So I
> suggest to return None if the parser does not parse the information.
>
> What do you think? This should be possible with minimal effort.
>
>

The parsing side of this is trivial - the only piece missing is
how best to present the information in the SeqRecord for
BioSQL compatibility (and perhaps some extra work on our
BioSQL bindings). That requires someone to test where
BioPerl stores this in BioSQL (as that is the reference
implementation).

Without that, a "quick fix" will mostly likely create a bug in
our BioSQL support - in that we wouldn't store the circular
field in the same way as the other Bio* implementations.

Peter
Permalink | Reply | 1 comment |
headers
redmine | 4 May 2012 21:33

[Biopython - Bug #3349] (New) Bio.PDB.Entity.copy child handling errors.


Issue #3349 has been reported by Alexander Ford.

----------------------------------------
Bug #3349: Bio.PDB.Entity.copy child handling errors.
https://redmine.open-bio.org/issues/3349

Author: Alexander Ford
Status: New
Priority: Normal
Assignee: 
Category: 
Target version: 
URL: https://github.com/asford/biopython/tree/entity_copy_fix

The Bio.PDB.Entity.copy function, introduced in revision 0d8299a9, does not properly handle the entity
child list. Iteration over the child_dict results in a loss of child ordering and the explicit call to
detach_child results in a destructive modification of the copied entity's child elements' parent reference.

The copy function should instead instantiate empty child_list and child_dict elements in the copy object
and then add copies of each element in the source object's child_list via the Entity.add function. This
will appropriately update the copy's child_dict and the child's parent reference while preserving
child ordering.

----------------------------------------
You have received this notification because this email was added to the New Issue Alert plugin

--

-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here and login: http://redmine.open-bio.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Cock | 5 May 2012 11:04
Gravatar

Fwd: [biopython] Fixing Entity copy method to preserve child ordering. (#37)

Who wants to review this one?

Peter

---------- Forwarded message ----------
From: *asford*
Date: Friday, May 4, 2012
Subject: [biopython] Fixing Entity copy method to preserve child ordering.
(#37)
To: Peter Cock <p.j.a.cock <at> googlemail.com>

Pull request to fix issue #3349.

You can merge this Pull Request by running:

 git pull https://github.com/asford/biopython entity_copy_fix

Or you can view, comment on it, or merge it online at:

 https://github.com/biopython/biopython/pull/37

-- Commit Summary --

* Fixing Entity copy method to preserve child ordering.

-- File Changes --

M Bio/PDB/Entity.py (11)

-- Patch Links --
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Talevich | 5 May 2012 18:09
Picon
Gravatar

Re: Fwd: [biopython] Fixing Entity copy method to preserve child ordering. (#37)

I'll check it out today.

On Sat, May 5, 2012 at 5:04 AM, Peter Cock <p.j.a.cock <at> googlemail.com>wrote:

> Who wants to review this one?
>
> Peter
>
> ---------- Forwarded message ----------
> From: *asford*
> Date: Friday, May 4, 2012
> Subject: [biopython] Fixing Entity copy method to preserve child ordering.
> (#37)
> To: Peter Cock <p.j.a.cock <at> googlemail.com>
>
>
> Pull request to fix issue #3349.
>
> You can merge this Pull Request by running:
>
>  git pull https://github.com/asford/biopython entity_copy_fix
>
> Or you can view, comment on it, or merge it online at:
>
>  https://github.com/biopython/biopython/pull/37
>
> -- Commit Summary --
>
> * Fixing Entity copy method to preserve child ordering.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tiago Antão | 6 May 2012 13:16
Picon
Gravatar

Re: [Biopython] Fwd: 2012 SciPy Bioinformatics Workshop

Hi,

On Sun, May 6, 2012 at 12:09 PM, Peter Cock <p.j.a.cock <at> googlemail.com> wrote:
> SciPy 2012 as a whole does clash with ISMB, and for those in Europe, it
> clashes with the planned CodeFest too:
> http://www.open-bio.org/wiki/EU_Codefest_2012

Are any people from here going to the codefest?

Tiago
Permalink | Reply | 1 comment |

Gmane