From bugzilla-daemon at portal.open-bio.org Thu Nov 1 00:35:13 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 1 Nov 2007 00:35:13 -0400
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711010435.lA14ZD0G010559@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #8 from mdehoon at ims.u-tokyo.ac.jp 2007-11-01 00:35 EST -------
> > 3) The sequence should be mutable, so that we won't need a separate
> > MutableSeq class. This also implies that a Seq class cannot subclass from
> > string, since strings are not mutable.
>
> Why? Python strings are not mutable, and this isn't usually a problem.
> Personally, I have never needed a mutable sequence and have only ever
> used them in test cases.
For my research, I do need a mutable sequence.
> Having the basic Seq non-mutable means we can leverage existing
> string functionality and optimizations.
Thinking this over, I can see one more pressing reason to keep the basic Seq
immutable: If Seq is immutable, it can be used as the key in a dictionary, and
as a member of a set. With a mutable Seq, neither is possible. So I guess we
need to keep both a Seq and a MutableSeq class. We'll have to write a clearer
explanation though in the tutorial as to why two classes are needed.
> Also writing a new mutable sequence in C seems like a bit maintainance load in
> the long term (and may complicate the cross platform build process).
> Surely we can get good enough performance via the array of characters
> route currently used?
The array of characters approach allows us fast modification of sequences. On
the other hand, things like taking the complement is much slower than for
strings. I looked around a bit in the Python standard library and found that
there already is a MutableString class (located in the UserString module).
Since this class stores a immutable string internally, it is as fast as a
string. So how about letting the basic Seq class inherit from string, and the
MutableSeq class from MutableString?
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 1 04:49:44 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 1 Nov 2007 04:49:44 -0400
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711010849.lA18nieV030106@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #9 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-01 04:49 EST -------
> For my research, I do need a mutable sequence.
Diffent work, different needs.
> > Having the basic Seq non-mutable means we can leverage existing
> > string functionality and optimizations.
>
> Thinking this over, I can see one more pressing reason to keep the
> basic Seq immutable: If Seq is immutable, it can be used as the key
> in a dictionary, and as a member of a set. With a mutable Seq, neither
> is possible. So I guess we need to keep both a Seq and a MutableSeq class.
Those are both good points. The dictionary key thing is something I have used,
but hadn't thought about in my last comment.
> We'll have to write a clearer explanation though in the tutorial as to
> why two classes are needed.
Fair point.
> The array of characters approach allows us fast modification of sequences.
> On the other hand, things like taking the complement is much slower than for
> strings. I looked around a bit in the Python standard library and found that
> there already is a MutableString class (located in the UserString module).
> Since this class stores a immutable string internally, it is as fast as a
> string. So how about letting the basic Seq class inherit from string, and
> the MutableSeq class from MutableString?
That does sound sensible. One side effect of subclassing directly is the .data
property will vanish (the internal string/array of the Seq/MutableSeq object).
Some people will be using this (especially as it was actually used in some
older versions of the tutorial).
I propose we make the Seq/MutableSeq object act more string like (fix
str(my_seq) etc) for the next release and officially declare the .data
deprecated in the documentation. This should be backwards compatible - expect
where anyone used the str(my_seq) to get a truncated string deliberately. Then
shift to actual subclasses for a later release.
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 1 05:14:43 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 1 Nov 2007 05:14:43 -0400
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711010914.lA19EhEJ031362@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #6 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-01 05:14 EST -------
We may have two bugs here.
First of all your original problem, TypeError: not all arguments converted
during string formatting
If you could post the SQL query and the argument list (sql and arg) it might be
helpful. We should check that the data we are trying to insert into the
database matches the fields in the table.
Then we come to the new error, AttributeError: 'Cursor' object has no attribute
'insert_id'
I found a question on our own mailing list from Bela Tiwari, 4 November 2005
which shares this new problem and may shed some light on what is going wrong:
Begin quote
-------------------------------------------------------------------
Hello,
I am new to using biopython and biosql. I have been following the information
in the document Basic BioSQL with Biopython to try and get familiar with using
biopython to work with mysql databases and specifically I have tried to load a
Genbank file containing a small bacterial genome into a database.
I believe I have carried out all the instructions correctly (i.e. interpreted
to fit the system I am working on - Debian Sarge). The code and traceback call
that results is:
#############################
>>> >>> from BioSQL import BioSeqDatabase
>>> >>> from Bio import GenBank
>>> >>> server = BioSeqDatabase.open_database(driver="MySQLdb", user="root", host="localhost", db="bioseqdb")
>>> >>> db = server.new_database("testorama7")
>>> >>> parser = GenBank.FeatureParser()
>>> >>> iterator = GenBank.Iterator(open("CP000010.gbk"), parser)
>>> >>> db.load(iterator)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/site-packages/BioSQL/BioSeqDatabase.py", line 414,
in load
db_loader.load_seqrecord(cur_record)
File "/usr/lib/python2.3/site-packages/BioSQL/Loader.py", line 37, in
load_seqrecord
bioentry_id = self._load_bioentry_table(record)
File "/usr/lib/python2.3/site-packages/BioSQL/Loader.py", line 225, in
_load_bioentry_table
taxon_id = self._get_taxon_id(record)
File "/usr/lib/python2.3/site-packages/BioSQL/Loader.py", line 198, in
_get_taxon_id
taxon_id = self.adaptor.last_id("taxon")
File "/usr/lib/python2.3/site-packages/BioSQL/BioSeqDatabase.py", line 148,
in last_id
return self.dbutils.last_id(self.cursor, table)
File "/usr/lib/python2.3/site-packages/BioSQL/DBUtils.py", line 34, in
last_id
return cursor.insert_id()
AttributeError: 'Cursor' object has no attribute 'insert_id'
################################
I have seen information on the web suggesting that MySQLdb has undergone an API
change such that the insert_id() function has moved from the cursor to the
database object. Is it possible that such a change is at the core of my
problem? Or have I just done something wrong?
I am working on Debian Sarge, using biopython version 1.40b (though I have
checked the code for the latest release and nothing under BioSQL has changed).
Any advice anyone has about how to sort out this error would be greatly
appreciated.
cheers
Bela
-------------------------------------------------------------------
end quote.
Sadly I can't see any follow up emails, nor did she file a bug at the time, so
it looks like this issue was forgotten about.
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 1 05:24:21 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 1 Nov 2007 05:24:21 -0400
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711010924.lA19OL9K032066@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #7 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-01 05:24 EST -------
Created an attachment (id=801)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=801&action=view)
Untested patch to BioSQL/DBUtils.py
Based on a little google searching, this is my completely untested educated
guess for how to fix the cursor problem in BioSQL/DBUtils.py with the relevant
changed bit of code below:
class Mysql_dbutils(Generic_dbutils):
def last_id(self, cursor, table):
try :
#This worked on older versions of MySQL
return cursor.insert_id()
except AttributeError:
#See bug 2390.
#Google suggests this is the new way:
return cursor.lastrowid
If you feel brave and don't know how to work with patches, just back the
original file and then edit the class Mysql_dbutils to look like the above.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 5 11:22:22 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 5 Nov 2007 11:22:22 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711051622.lA5GMMxB008819@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #8 from Biosql at hotmail.com 2007-11-05 11:22 EST -------
Hi Peter,
Here's the SQL query :
INSERT INTO bioentry (
biodatabase_id,
name,
accession,
identifier,
division,
description,
version)
VALUES (%s,
%s,
%s,
%s,
%s,
%s,)"""
self.adaptor.execute(sql, (self.dbid, record.name,
accession,identifier,
division, description, version))
You can see there's a missing %s.
There's also a similar error in DBUtils module at line 23, where an argument is
also missing.
sql = r"select max(%s_id) from %s" % table
I've change the line with this one :
sql = r"select max(%s_id) from %s" % (table, table)
I also tried your suggested patch and I'm not receiving any error since, which
is great ! But, nothing's getting uploaded in the database... Crap...
Again, many thanks for the help 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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 5 14:49:40 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 5 Nov 2007 14:49:40 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711051949.lA5JnevZ004884@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #9 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-05 14:49 EST -------
Issue One
---------
Missing %s in BioSQL/Loader.py approx line 240. I think that as you suggest,
we should add a %s here.
This was removed in CVS version 1.18 (June 2007) by Michiel while working on
bug 1982. I think only one %s was meant to be removed (when the taxon_id was
removed), but it got done twice with the two related CVS commits.
Issue Two
---------
The cursor problem. I don't know if my suggestion in comment 7 is working or
not - it could be something else is going wrong to result in nothing in the
database.
Issue Three
-----------
Missing table argument in BioSQL/DBUtils.py line 23, I agree with you and have
fixed this in CVS revision 1.4.
In normal use the object is subclassed and the broken last_id method would
never have been called.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 5 16:49:09 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 5 Nov 2007 16:49:09 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711052149.lA5Ln9eC022511@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #10 from Biosql at hotmail.com 2007-11-05 16:49 EST -------
I'm using the DButils.py for now and it's working fine.
Now, I've checked the uploading problem with the BioSQL database and it seems
to me that It's getting stuck right at the beginning of the import with this
sql query :
INSERT INTO biodatabase (name, authority, description) VALUES ('Swiss', NULL,
NULL)
So, I've tried to repeat the same sql query in manual mode and I'm getting this
error :
1205, 'Lock wait timeout exceeded; try restarting transaction'
This error seems to be related to Innodb transaction.
Since, I'm very newb with InnoDB, cuz I've always been using MyISAM table I
really don't know what to do. Well, at least I'm gonna read on InnoDB table.
Thanks !
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 6 03:59:31 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 6 Nov 2007 03:59:31 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711060859.lA68xVZE014591@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #11 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-06 03:59 EST -------
> Now, I've checked the uploading problem with the BioSQL database and it
> seems to me that It's getting stuck right at the beginning of the import
> with this sql query :
>
> INSERT INTO biodatabase (name, authority, description)
> VALUES ('Swiss', NULL, NULL)
Do you know how to check the table schema, and see if authority and description
can be left empty/NULL?
I'm not sure what "authority" should be in this context, but it does strike me
as odd that the description is NULL - that could be a sequence file parsing
issue. Does this happen for all files you've tried - what about a GenBank
example?
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 6 23:55:50 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 6 Nov 2007 23:55:50 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711070455.lA74toCr023587@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #10 from mdehoon at ims.u-tokyo.ac.jp 2007-11-06 23:55 EST -------
> One side effect of subclassing directly is the .data property will vanish
> (the internal string/array of the Seq/MutableSeq object).
> Some people will be using this (especially as it was actually used in some
> older versions of the tutorial).
If we add
self.data = self
in the __init__ method of the Seq/MutableSeq classes, then the .data property
can still be used as before, without using significantly more memory.
> I propose we make the Seq/MutableSeq object act more string like (fix
> str(my_seq) etc) for the next release and officially declare the .data
> deprecated in the documentation. This should be backwards compatible - expect
> where anyone used the str(my_seq) to get a truncated string deliberately.
> Then shift to actual subclasses for a later release.
As we can keep the seq.data property even after subclassing, how about
subclassing right away for the next release?
--
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.
From tiagoantao at gmail.com Wed Nov 7 06:09:44 2007
From: tiagoantao at gmail.com (Tiago Antao)
Date: Wed, 07 Nov 2007 11:09:44 +0000
Subject: [Biopython-dev] resuming CVS updates
Message-ID: <47319CF8.8020507@gmail.com>
Hi,
Is it OK to resume with CVS updates of non-production code? (No rush or
urgency, just to know...)
Tiago
--
tiagoantao at gmail.com
http://tiago.org/ps
From mdehoon at c2b2.columbia.edu Wed Nov 7 20:06:03 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Wed, 7 Nov 2007 20:06:03 -0500
Subject: [Biopython-dev] resuming CVS updates
References: <47319CF8.8020507@gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B656@mail2.exch.c2b2.columbia.edu>
Since no disasters showed up with the 1.44 release, I think it is OK to
resume CVS updates.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
-----Original Message-----
From: biopython-dev-bounces at lists.open-bio.org on behalf of Tiago Antao
Sent: Wed 11/7/2007 6:09 AM
To: biopython-dev at biopython.org
Subject: [Biopython-dev] resuming CVS updates
Hi,
Is it OK to resume with CVS updates of non-production code? (No rush or
urgency, just to know...)
Tiago
--
tiagoantao at gmail.com
http://tiago.org/ps
_______________________________________________
Biopython-dev mailing list
Biopython-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biopython-dev
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 07:34:07 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 07:34:07 -0500
Subject: [Biopython-dev] [Bug 2393] New: Bio.GenBank.NCBIDictionary fails
with release 1.44
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
Summary: Bio.GenBank.NCBIDictionary fails with release 1.44
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Main Distribution
AssignedTo: biopython-dev at biopython.org
ReportedBy: mdehoon at ims.u-tokyo.ac.jp
In Biopython release 1.44, some magic code in Bio/__init__.py was removed. This
causes Bio.GenBank.NCBIDictionary to fail, since Bio.db is no longer known. See
this message from Eric Gibert on the mailing list:
http://lists.open-bio.org/pipermail/biopython/2007-November/003876.html
This code example shows the error:
>>> from Bio.GenBank import NCBIDictionary
>>> d = NCBIDictionary("nucleotide","genbank")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/site-packages/Bio/GenBank/__init__.py", line 1283,
in
__init__
from Bio import db
ImportError: cannot import name db
>>>
The attached patch is a first attempt to resurrect the NCBIDictionary
functionality, using NCBI's EUtils directly instead of going though Bio.db. One
important difference is that __getitem__ now returns a handle instead of the
record contents. NCBIDictionary can then be used as follows:
>>> from Bio.GenBank import NCBIDictionary
>>> d = NCBIDictionary("nucleotide","genbank")
>>> handle = d['57282195']
>>> from Bio import SeqIO
>>> record = SeqIO.parse(handle, "genbank").next()
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 07:35:09 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 07:35:09 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711081235.lA8CZ9oo020618@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
mdehoon at ims.u-tokyo.ac.jp changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|biopython-dev at biopython.org |mdehoon at ims.u-tokyo.ac.jp
Status|NEW |ASSIGNED
------- Comment #1 from mdehoon at ims.u-tokyo.ac.jp 2007-11-08 07:35 EST -------
Created an attachment (id=803)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=803&action=view)
Patch for Bio/GenBank/__init__.py
--
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.
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 11:26:00 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:26:00 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711081626.lA8GQ0kA032150@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #801 is|0 |1
obsolete| |
------- Comment #12 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-08 11:25 EST -------
(From update of attachment 801)
Checked into CVS, see BioSQL/DBUtils.py revision 1.5, after Eric Gibert
suggested the same fix on the mailing list.
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 11:36:26 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:36:26 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711081636.lA8GaQTG000341@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #13 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-08 11:36 EST -------
Issue One
---------
Missing %s in BioSQL/Loader.py approx line 240. Fixed in CVS, BioSQL/Loader.py
revision 1.19
Issue Two
---------
The cursor problem. I've checked in the suggested fix from my comment 7, Eric
Gibert suggested the same thing on the mailing list.
Eric's email suggests we also have to do something about finishing the SQL
transaction - i.e. actually doing a commit to save the inserted records in the
databse.
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 11:47:10 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:47:10 -0500
Subject: [Biopython-dev] [Bug 2394] New: INSERT INTO
seqfeature_qualifier_value ...
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2394
Summary: INSERT INTO seqfeature_qualifier_value ...
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
Reported on the mailing list by Eric Gibert, as pointed out by Hilmar Lapp any
SQL statement which relies on the field order not changing is fragile. My
patch to follow...
Eric wrote:
In my BioSQL database, the table 'seqfeature_qualifier_value' as the following
schema:
seqfeature_id int(11)
term_id int(11)
value varchar(255)
rank int(11)
note that first we have 'value' then we have 'rank'.
But the 'INSERT INTO seqfeature_qualifier_value' statement found in
BioSQL/Loader.py line 453 is:
qualifier_value =
qualifiers[qualifier_key][qual_value_rank]
sql = r"INSERT INTO seqfeature_qualifier_value VALUES" \
r" (%s, %s, %s, %s)"
self.adaptor.execute(sql, (seqfeature_id,
qualifier_key_id,
qual_value_rank + 1,
qualifier_value))
thus I need to invert the last two elements of the list. As I said, I do not
know if my BioSQL schema is correct or not.
If my schema is correct then my correction is obvious:
self.adaptor.execute(sql, (seqfeature_id,
qualifier_key_id,
qualifier_value, # EG
invert the two last params
qual_value_rank + 1
))
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 11:49:05 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:49:05 -0500
Subject: [Biopython-dev] [Bug 2394] INSERT INTO seqfeature_qualifier_value
...
In-Reply-To:
Message-ID: <200711081649.lA8Gn57i001263@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2394
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-08 11:49 EST -------
Created an attachment (id=804)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=804&action=view)
Patch to BioSQL/Loader.py
List the fields explicitly in the SQL statement.
See also:
http://www.bioperl.org/SRC/biosql-schema/sql/biosqldb-mysql.sql
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 11:55:15 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:55:15 -0500
Subject: [Biopython-dev] [Bug 2394] INSERT INTO seqfeature_qualifier_value
...
In-Reply-To:
Message-ID: <200711081655.lA8GtFRp001632@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2394
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-08 11:55 EST -------
If Eric is reading this, could you tell us where you got your BioSQL database
schema from? Your column order differs from what I would expect from these:
http://www.bioperl.org/SRC/biosql-schema/sql/biosqldb-mysql.sql
http://www.bioperl.org/SRC/biosql-schema/sql/biosqldb-pg.sql
With the patch, Biopython should cope with the fields in this table being in
any order.
--
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.
From bugzilla-daemon at portal.open-bio.org Fri Nov 9 01:04:50 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 9 Nov 2007 01:04:50 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711090604.lA964oVN001747@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
mdehoon at ims.u-tokyo.ac.jp changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |biopython-dev at biopython.org
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Fri Nov 9 05:55:24 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 9 Nov 2007 05:55:24 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711091055.lA9AtO2Y014627@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #4 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-09 05:55 EST -------
Creating a new handle based interface, and using this internally within
Bio.GenBank.NCBIDictionary to provide the old API sounds very sensible. As you
say, we /could/ then one day deprecate Bio.GenBank.NCBIDictionary.
Your point about avoiding UEtils is understandable. How about using the far
simpler Bio.WWW.NCBI wrapper? This has basic error checking and means hard
coding the URL in one place only. In fact, this could be a good place to put a
new Dictionary, e.g. Bio.WWW.NCBI.EntrezDictionary rather than
Bio.Entrez.Dictionary
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Fri Nov 9 07:04:09 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 9 Nov 2007 07:04:09 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711091204.lA9C49OT017953@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #5 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-09 07:04 EST -------
Created an attachment (id=805)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=805&action=view)
Possible new unit test
This is a possible unit test which uses
Bio.GenBank.NCBIDictionary and a few other online sources of data, and checks
we can parse them with Bio.SeqIO
I have been testing this with my one line short term import hack (checked in by
the way - with the expectation your code will replace it). Note that this does
give a DeprecationWarning from Bio/config/DBRegistry.py
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 01:35:27 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 01:35:27 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711120635.lAC6ZRFD023790@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #6 from mdehoon at ims.u-tokyo.ac.jp 2007-11-12 01:35 EST -------
> Your point about avoiding UEtils is understandable. How about using the far
> simpler Bio.WWW.NCBI wrapper? This has basic error checking and means hard
> coding the URL in one place only. In fact, this could be a good place to put a
> new Dictionary, e.g. Bio.WWW.NCBI.EntrezDictionary rather than
> Bio.Entrez.Dictionary
I'd be happy to use the code from Bio.WWW.NCBI, but I don't think that Bio.WWW
is a good location for an EntrezDictionary class. As a case in point, I didn't
know that Bio.WWW contains code to access NCBI Entrez, and I couldn't guess it
from its name. With a module like Bio.GenBank, it is clear from its name what
it is about. Furthermore, the different submodules Bio.WWW.ExPASy,
Bio.WWW.InterPro, Bio.WWW.NCBI, and Bio.WWW.SCOP don't seem to have much in
common. I think that the existing modules Bio.SwissProt, Bio.Prosite,
Bio.InterPro, Bio.SCOP, containing the respective parsers, are more logical
places to keep the database access code.
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 05:25:32 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 05:25:32 -0500
Subject: [Biopython-dev] [Bug 2395] New: Need a commit in db.load (BioSQL
with MySQL)
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
Summary: Need a commit in db.load (BioSQL with MySQL)
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
As noted in bug 1921 and more recently on the mailing and bug 2390, it seem
Biopython should be doing a database commit with MySQL.
e.g. Leighton Pritchard wrote on bug 1921 comment 3
>>> from BioSQL import BioSeqDatabase
>>> server = BioSeqDatabase.open_database(driver="MySQLdb", user="root", passwd=
"", host="localhost", db="bioseqdb")
>>> db = server.new_database("cold")
>>> from Bio import GenBank
>>> parser = GenBank.FeatureParser()
>>> iterator = GenBank.Iterator(file("cor6_6.gb"), parser)
>>> db.load(iterator)
6
>>>
However, there is now an additional new problem when using MySQL5, as the
necessary commit is not automatically executed, and a direct call of
>>> server.adaptor.commit()
seems to be necessary after the above in order to commit the changes to the
database.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 05:26:33 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 05:26:33 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711121026.lACAQXlS002017@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #14 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-12 05:26 EST -------
Issue Two
---------
The cursor problem. As I said, I've checked in the suggested fix from my
comment 7, since Eric Gibert suggested the same thing on the mailing list.
More or less the same issue was reported as bug 1979 with a slightly
different solution: http://bugzilla.open-bio.org/show_bug.cgi?id=1979
Regarding the cursor problem, reading up on bug 1921, since perhaps MySQL 5,
Biopython has needed to manually do a commit. I've filed bug 2395
http://bugzilla.open-bio.org/show_bug.cgi?id=1921
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 05:30:56 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 05:30:56 -0500
Subject: [Biopython-dev] [Bug 1921] BioSeqDatabase.load() method fails
In-Reply-To:
Message-ID: <200711121030.lACAUuqA002275@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=1921
------- Comment #8 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-12 05:30 EST -------
I've filed bug 2395 on the commit issue as that seems to still be outstanding.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 07:32:05 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 07:32:05 -0500
Subject: [Biopython-dev] [Bug 1921] BioSeqDatabase.load() method fails
In-Reply-To:
Message-ID: <200711121232.lACCW5ST008594@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=1921
mcolosimo at mitre.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mcolosimo at mitre.org
------- Comment #9 from mcolosimo at mitre.org 2007-11-12 07:32 EST -------
(In reply to comment #6)
> Hi Michiel,
>
> I've had no further issues since I put in the patch locally, so it works for
> me, at least. No doubt someone will point out any further problems that I've
> missed in my usage ;)
>
> L.
>
Does this fix what I reported and submitted?
Marc
--
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.
From mdehoon at c2b2.columbia.edu Tue Nov 13 01:52:54 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 01:52:54 -0500
Subject: [Biopython-dev] Bio.WWW; database access
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
Hi everybody,
Recently Eric Gibert wrote to us about Bio.GenBank.NCBIDictionary failing
with Biopython 1.44. We already have a fix for this error in CVS, but when I
was looking into this bug in more detail I started wondering about the way
database access is organized in Biopython.
Currently, code to access NCBI Entrez exists in three places:
1) Bio.WWW.NCBI
2) Bio.GenBank (in NCBIDictionary)
3) Bio.EUtils
Bio.WWW contains three more submodules for database access:
1) Bio.WWW.ExPASy, to access Swissprot, Prodoc, Prosite
2) Bio.WWW.InterPro, to access InterPro
3) Bio.WWW.SCOP, to access the SCOP database
The parsers for these modules are in a different location:
1a) Bio.SwissProt
1b) Bio.Prosite
1c) Bio.Prosite.Prodoc
2) Bio.InterPro
3) Bio.SCOP
To me, it seems odd that the code for database access and the code to parse
files downloaded from the database are in different locations. For example,
when I was working on Bio.GenBank, it did not occur to me that such code
might already exist in Bio.WWW.
Now, Bio.WWW.SCOP is a very small module (64 lines total), and
Bio.WWW.InterPro seems to be out of date. With Bio.WWW.NCBI containing
functionality that also exists elsewhere in Biopython, having a separate
Bio.WWW module doesn't seem to be optimal in terms of code organization. I'd
prefer to have the code for database access together with the respective code
for parsing.
Any opinions?
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 04:24:31 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 04:24:31 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711130924.lAD9OV2K014516@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #7 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 04:24 EST -------
Michiel has moved this discussion to the developers' mailing list.
> I'd be happy to use the code from Bio.WWW.NCBI, but I don't think that
> Bio.WWW is a good location for an EntrezDictionary class. As a case in point,
> I didn't know that Bio.WWW contains code to access NCBI Entrez, and I
> couldn't guess it from its name.
I correctly guessed from the name Bio.WWW.NCBI that it was an API for the
NCBI's online tools (but I tend to refer to the NCBI rather than Entrez in
conversation).
> With a module like Bio.GenBank, it is clear from its name what it is about.
Yes, it does mean both the file format and the online database.
> Furthermore, the different submodules Bio.WWW.ExPASy, Bio.WWW.InterPro,
> Bio.WWW.NCBI, and Bio.WWW.SCOP don't seem to have much in common.
Apart from all being interfaces to online/web databases? Well no, but if this
was followed more strictly it would make the top level module list much
shorter.
> I think that the existing modules Bio.SwissProt, Bio.Prosite, Bio.InterPro,
> Bio.SCOP, containing the respective parsers, are more logical places to keep
> the database access code.
Maybe. I agree we should rationalise things, and getting rid of Bio.WWW might
be the most straight forward simplification - see mailing list.
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From tiagoantao at gmail.com Tue Nov 13 04:30:50 2007
From: tiagoantao at gmail.com (Tiago Antao)
Date: Tue, 13 Nov 2007 09:30:50 +0000
Subject: [Biopython-dev] uploading coalescent code
Message-ID: <47396ECA.2060902@gmail.com>
Hi,
I am going to start uploading coalescent code (unless somebody disagrees).
A few points about this code:
1. It was already published and has users (google for modeler4simcoal2),
so it should be fairly stable.
2. It has some purpose and hopefully some audience (the code that is in
Bio.PopGen currently is for less important things - is was used by
myself mainly to get acquainted with the developer process).
3. IMPORTANT: There are some text template files. I suppose that there
is no standard way to have datafiles around. I was thinking (actually
somebody suggested on this list) in putting it alongside the code.
Question: Is there any standard way to know where biopython is installed
(so that I can read those datafiles)? We are talking of very small files.
Thanks,
Tiago
--
tiagoantao at gmail.com
http://tiago.org/ps
From biopython-dev at maubp.freeserve.co.uk Tue Nov 13 04:10:41 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Tue, 13 Nov 2007 09:10:41 +0000
Subject: [Biopython-dev] Bio.WWW; database access
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
Message-ID: <47396A11.8020705@maubp.freeserve.co.uk>
Michiel De Hoon wrote:
> Hi everybody,
>
> Recently Eric Gibert wrote to us about Bio.GenBank.NCBIDictionary failing
> with Biopython 1.44. We already have a fix for this error in CVS, but when I
> was looking into this bug in more detail I started wondering about the way
> database access is organized in Biopython.
See also bug 2393 for the background to this discussion.
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
> Currently, code to access NCBI Entrez exists in three places:
> 1) Bio.WWW.NCBI
> 2) Bio.GenBank (in NCBIDictionary)
> 3) Bio.EUtils
>
> Bio.WWW contains three more submodules for database access:
> 1) Bio.WWW.ExPASy, to access Swissprot, Prodoc, Prosite
> 2) Bio.WWW.InterPro, to access InterPro
> 3) Bio.WWW.SCOP, to access the SCOP database
>
> The parsers for these modules are in a different location:
> 1a) Bio.SwissProt
> 1b) Bio.Prosite
> 1c) Bio.Prosite.Prodoc
> 2) Bio.InterPro
> 3) Bio.SCOP
>
> To me, it seems odd that the code for database access and the code to parse
> files downloaded from the database are in different locations. For example,
> when I was working on Bio.GenBank, it did not occur to me that such code
> might already exist in Bio.WWW.
My initially reaction was different - having noticed there was a WWW
module (it caught my eye being the last directory) I initially looked
there for online resources.
> Now, Bio.WWW.SCOP is a very small module (64 lines total), and
> Bio.WWW.InterPro seems to be out of date. With Bio.WWW.NCBI containing
> functionality that also exists elsewhere in Biopython, having a separate
> Bio.WWW module doesn't seem to be optimal in terms of code organization. I'd
> prefer to have the code for database access together with the respective code
> for parsing.
>
> Any opinions?
I do agree that having things in two places is not optimal for new
users, and on balance having code to access the online resource
associated with a file format in the same place as the parsers seems
reasonable.
However, what about the fact that some online resources (e.g. GenBank)
will return several sorts of data (e.g. journal references and
sequences) and/or in a range of file formats (e.g. GenBank, Fasta, XML,
...). In this situation, having the online interface separate from the
format parsers makes some sense. I am perhaps being a devil's advocate
here.
Peter
From mdehoon at c2b2.columbia.edu Tue Nov 13 04:52:44 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 04:52:44 -0500
Subject: [Biopython-dev] uploading coalescent code
References: <47396ECA.2060902@gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65C@mail2.exch.c2b2.columbia.edu>
Hi Tiago,
> 3. IMPORTANT: There are some text template files. I suppose that there
> is no standard way to have datafiles around. I was thinking (actually
> somebody suggested on this list) in putting it alongside the code.
> Question: Is there any standard way to know where biopython is installed
> (so that I can read those datafiles)? We are talking of very small files.
Have you looked at the manual for distutils? Section 2.6 and 2.7 discuss
having data files distributed with a Python extension. See
http://docs.python.org/dist/dist.html
Given that such an option exists, somebody must already be using it. So I
think your best option is to google around a bit to find some examples.
--Michiel
From biopython-dev at maubp.freeserve.co.uk Tue Nov 13 05:07:22 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Tue, 13 Nov 2007 10:07:22 +0000
Subject: [Biopython-dev] Biopython SVN Transition
In-Reply-To: <128a885f0710302255y4c34ac8axa48f48b253d5854a@mail.gmail.com>
References: <128a885f0710300717p7d91a4adjfaddc9c496974e67@mail.gmail.com> <47278655.8090300@maubp.freeserve.co.uk>
<128a885f0710302255y4c34ac8axa48f48b253d5854a@mail.gmail.com>
Message-ID: <4739775A.1020208@maubp.freeserve.co.uk>
Chris Lasher wrote:
>> In terms of timing, how long do you/the OBF guys expect the transfer to
>> take? And would they prefer to do this over a weekend or mid week?
>
> Not sure, let me ask Jason Stajich.
> ...
> I think we could expect less than a full day downtime.
Any preference on mid week versus weekend? I'm still happy with any time
in the next fortnight.
>> P.S. Would you or any of the people doing the transition be able to sort
>> out bug 2363?
>> http://bugzilla.open-bio.org/show_bug.cgi?id=2363
>
> That's a very good question. I wonder if cvs2svn is capable of picking
> up those errors in commits and choose the proper format. I had trouble
> getting a hold of an expert who could tell me how to identify files
> committed as binary files, and how to change that to text (or vice
> versa). I should send an email to the Subversion mailing list,
> perhaps, or the CVS list if it's still active. I'll also check to see
> if Jason knows.
If you can solve this, it would make life easier for building from
source on Windows :)
Thanks
Peter
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 05:23:59 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 05:23:59 -0500
Subject: [Biopython-dev] [Bug 2380] Bio.Nexus is adding "?" and "-" to
Bio.Data.IUPACData.ambiguous_dna_values
In-Reply-To:
Message-ID: <200711131023.lADANxcg017625@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2380
tiagoantao at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tiagoantao at gmail.com
------- Comment #1 from tiagoantao at gmail.com 2007-11-13 05:23 EST -------
As I found this, I already have some knowledge of the problem.
I am volunteering to try to solve it.
If somebody would prefer me not to do this, please say. If not, in a couple of
days I will assign it to myself and start working.
--
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.
From tiagoantao at gmail.com Tue Nov 13 05:25:32 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Tue, 13 Nov 2007 10:25:32 +0000
Subject: [Biopython-dev] uploading coalescent code
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B65C@mail2.exch.c2b2.columbia.edu>
References: <47396ECA.2060902@gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B65C@mail2.exch.c2b2.columbia.edu>
Message-ID: <6d941f120711130225u7d6041e5n8dc6a70f1df2a945@mail.gmail.com>
Hi,
I should have done my home work better before asking this in the list, sorry.
According to the manual, there are 2 options:
# 2.6 Installing Package Data
# 2.7 Installing Additional Files
Being strictly correct, we are talking about "additional files", but,
to make things simpler (and avoiding clutering biopython with probably
more top-level directories) I think "package data" is enough.
If nobody sees a problem I will add a data directory inside
Bio/PopGen/SimCoal and upload it to CVS.
But, there is a more serious change: setup.py. For this I suggest:
1. Adding you to the SimCoal feature bug 2375, can I do that?
2. I would put my suggested diff there and you could
evaluate/change/accept/reject it
On Nov 13, 2007 9:52 AM, Michiel De Hoon wrote:
> Hi Tiago,
>
> > 3. IMPORTANT: There are some text template files. I suppose that there
> > is no standard way to have datafiles around. I was thinking (actually
> > somebody suggested on this list) in putting it alongside the code.
> > Question: Is there any standard way to know where biopython is installed
> > (so that I can read those datafiles)? We are talking of very small files.
>
> Have you looked at the manual for distutils? Section 2.6 and 2.7 discuss
> having data files distributed with a Python extension. See
>
> http://docs.python.org/dist/dist.html
>
> Given that such an option exists, somebody must already be using it. So I
> think your best option is to google around a bit to find some examples.
>
> --Michiel
>
>
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 05:36:42 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 05:36:42 -0500
Subject: [Biopython-dev] [Bug 2380] Bio.Nexus is adding "?" and "-" to
Bio.Data.IUPACData.ambiguous_dna_values
In-Reply-To:
Message-ID: <200711131036.lADAagXG018746@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2380
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 05:36 EST -------
I think Nexus should just create a copy of ambiguous_dna_values and any related
lists/dicts, and add things to the copy. I'm happy to review a patch if you
want to tackle this Tiago.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 06:18:41 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 06:18:41 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711131118.lADBIfPV021081@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Need a commit in db.load |Need a commit in BioSQL with
|(BioSQL with MySQL) |MySQL
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 06:18 EST -------
As might be expected with hindsight, this is more general than just db.load(),
and seems to apply to any operation.
One suggestion on the mailing list from Eric Gibert,
[quote]
Finally, the script executes without error and .... nothing happens! It looks
like there is no 'commit' nowhere and so the new records are not inserted in
the database.
Although the psychopg database enjoys a:
def autocommit(self, conn, y = True):
conn.autocommit(y)
_dbutils["psycopg"] = Psycopg_dbutils
MySQL does not have such an overload for 'autocommit' in DBUtils.py. Could this
fix the problem ?
In the file MySQLdb/connections.py, on line 213, we have:
# PEP-249 requires autocommit to be initially off
self.autocommit(False)
Therefore the source for the Mysql_dbutils class is now:
class Mysql_dbutils(Generic_dbutils):
def last_id(self, cursor, table):
return cursor.lastrowid #EG original command: cursor.insert_id()
def autocommit(self, conn, y = True): # EG addition as by default it is set
to False
conn.autocommit(y)
_dbutils["MySQLdb"] = Mysql_dbutils
Unfortunately, this is *NOT* fixing the lack of 'commit'. I need your help...
[/quote]
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 06:26:45 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 06:26:45 -0500
Subject: [Biopython-dev] [Bug 2394] INSERT INTO seqfeature_qualifier_value
...
In-Reply-To:
Message-ID: <200711131126.lADBQjMX021544@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2394
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 06:26 EST -------
Confirmed this change works fine, fix checked into CVS
biopython/BioSQL/Loader.py revision 1.21
Marking as fixed.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 06:30:41 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 06:30:41 -0500
Subject: [Biopython-dev] [Bug 2380] Bio.Nexus is adding "?" and "-" to
Bio.Data.IUPACData.ambiguous_dna_values
In-Reply-To:
Message-ID: <200711131130.lADBUf0G021925@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2380
tiagoantao at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|biopython-dev at biopython.org |tiagoantao at gmail.com
--
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.
You are the assignee for the bug, or are watching the assignee.
From mdehoon at c2b2.columbia.edu Tue Nov 13 06:32:08 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 06:32:08 -0500
Subject: [Biopython-dev] uploading coalescent code
References: <47396ECA.2060902@gmail.com><6243BAA9F5E0D24DA41B27997D1FD14402B65C@mail2.exch.c2b2.columbia.edu>
<6d941f120711130225u7d6041e5n8dc6a70f1df2a945@mail.gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65D@mail2.exch.c2b2.columbia.edu>
> But, there is a more serious change: setup.py. For this I suggest:
> 1. Adding you to the SimCoal feature bug 2375, can I do that?
> 2. I would put my suggested diff there and you could
> evaluate/change/accept/reject it
Sure, that is fine.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
On Nov 13, 2007 9:52 AM, Michiel De Hoon wrote:
> Hi Tiago,
>
> > 3. IMPORTANT: There are some text template files. I suppose that there
> > is no standard way to have datafiles around. I was thinking (actually
> > somebody suggested on this list) in putting it alongside the code.
> > Question: Is there any standard way to know where biopython is installed
> > (so that I can read those datafiles)? We are talking of very small files.
>
> Have you looked at the manual for distutils? Section 2.6 and 2.7 discuss
> having data files distributed with a Python extension. See
>
> http://docs.python.org/dist/dist.html
>
> Given that such an option exists, somebody must already be using it. So I
> think your best option is to google around a bit to find some examples.
>
> --Michiel
>
>
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 06:33:15 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 06:33:15 -0500
Subject: [Biopython-dev] [Bug 2386] Bio.Seq.Seq and MutableSeq count()
method only works for single residues
In-Reply-To:
Message-ID: <200711131133.lADBXF3l022073@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2386
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #6 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 06:33 EST -------
Marking as fixed, count method patch checked into CVS, see biopython/Bio/Seq.py
revision 1.20
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 07:52:46 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 07:52:46 -0500
Subject: [Biopython-dev] [Bug 2396] New: BioSQL loader does not store
sequence level annotations dict
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
Summary: BioSQL loader does not store sequence level annotations
dict
Product: Biopython
Version: 1.44
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
Reported on the mailing list by Eric Gibert.
Basically while features have their annotations recorded, most of the top level
SeqRecord's annotations dictionary is ignored.
I'm about to attach a possible patch; this still needs work for the case where
the annotations dictionary contains non-string values (e.g. lists of strings)
and I may want to tweak the reconstruction of the record on retreival from the
database.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 07:54:29 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 07:54:29 -0500
Subject: [Biopython-dev] [Bug 2396] BioSQL loader does not store sequence
level annotations dict
In-Reply-To:
Message-ID: <200711131254.lADCsTeE026220@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 07:54 EST -------
Created an attachment (id=806)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=806&action=view)
Patch to BioSQL/Loader.py
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 08:07:28 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 08:07:28 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711131307.lADD7SO4026877@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #15 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 08:07 EST -------
I haven't downloaded the 1GB uniprot_sprot.dat file, however using the example
files from biopython/Tests/SwissProt seems to work for me now using CVS:
from BioSQL import BioSeqDatabase
from Bio import SeqIO
import os
server = BioSeqDatabase.open_database(driver='MySQLdb', user='root', passwd='',
host='localhost', db='bioseqdb')
db = server.new_database('bug2390')
for filename in os.listdir(".") :
if filename[:2]=="sp" :uniprot_sprot.dat
print "Loading %s" % filename
db.load(SeqIO.parse(open(filename), "swiss"))
print "Committing..."
server.adaptor.commit()
The commit issue is covered by bug 2395, so I would like to mark this as fixed.
Jon - could you update your copy of Biopython and re-test? Thanks
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 11:12:27 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 11:12:27 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711131612.lADGCR0n004960@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #736 is|0 |1
obsolete| |
------- Comment #11 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 11:12 EST -------
(From update of attachment 736)
Something similar checked in as biopython/Bio/Seq.py revision 1.21
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 11:12:49 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 11:12:49 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711131612.lADGCnfi005023@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #751 is|0 |1
obsolete| |
------- Comment #12 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 11:12 EST -------
(From update of attachment 751)
Something similar checked in as biopython/Bio/Seq.py revision 1.21
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 11:15:26 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 11:15:26 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711131615.lADGFQTj005269@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #13 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 11:15 EST -------
I've updated the __str__ methods in CVS to act like strings; I'll take care of
the unit tests this breaks next.
> As we can keep the seq.data property even after subclassing, how
> about subclassing right away for the next release?
Maybe, but doing that properly that does mean a lot more work - we have to
implement alphabet aware versions all the string methods.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 13:19:46 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 13:19:46 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711131819.lADIJkpI012007@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #797 is|0 |1
obsolete| |
------- Comment #16 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 13:19 EST -------
(From update of attachment 797)
This attachment has been removed
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 13:19:53 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 13:19:53 -0500
Subject: [Biopython-dev] [Bug 2397] New: test_PopGen_FDist does not fail
gracefully on Windows
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2397
Summary: test_PopGen_FDist does not fail gracefully on Windows
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: Windows
Status: NEW
Severity: minor
Priority: P2
Component: PopGen
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
On Linux, test_PopGen_FDist.py can detect when the fdist program is missing,
and raises the missing external dependancy exception (trapped by the test
harness).
On Windows, this does not work properly - the OS error is not caught.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 13:20:31 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 13:20:31 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711131820.lADIKVOn012120@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #798 is|0 |1
obsolete| |
------- Comment #17 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 13:20 EST -------
(From update of attachment 798)
This attachment has been removed
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 13:23:25 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 13:23:25 -0500
Subject: [Biopython-dev] [Bug 2397] test_PopGen_FDist does not fail
gracefully on Windows
In-Reply-To:
Message-ID: <200711131823.lADINPXH012319@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2397
tiagoantao at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|biopython-dev at biopython.org |tiagoantao at gmail.com
------- Comment #1 from tiagoantao at gmail.com 2007-11-13 13:23 EST -------
I will install biopython on windows and correct this.
--
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.
You are the assignee for the bug, or are watching the assignee.
From mdehoon at c2b2.columbia.edu Tue Nov 13 21:16:06 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 21:16:06 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
<47396A11.8020705@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
> However, what about the fact that some online resources (e.g. GenBank)
> will return several sorts of data (e.g. journal references and
> sequences) and/or in a range of file formats (e.g. GenBank, Fasta, XML,
> ...). In this situation, having the online interface separate from the
> format parsers makes some sense.
I agree. My suggestion would be
1) Split Bio.WWW.ExPASy (access to Swissprot, Prodoc, Prosite) between
Bio.SwissProt, Bio.Prosite, and Bio.Prodoc as appropriate
2) Put Bio.WWW.InterPro in Bio.InterPro
3) Put Bio.WWW.SCOP in Bio.SCOP
4) NCBI Entrez is a special case since it contains many different sorts of
data. Bio.GenBank doesn't seem to be the best place for it, as NCBI Entrez is
much more than GenBank. I would therefore suggest to move Bio.WWW.NCBI to
Bio.Entrez (currently an empty module in Biopython), and merge this code with
the database access code in Bio.GenBank and Bio.EUtils.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From mdehoon at c2b2.columbia.edu Tue Nov 13 21:16:06 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 21:16:06 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
<47396A11.8020705@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
> However, what about the fact that some online resources (e.g. GenBank)
> will return several sorts of data (e.g. journal references and
> sequences) and/or in a range of file formats (e.g. GenBank, Fasta, XML,
> ...). In this situation, having the online interface separate from the
> format parsers makes some sense.
I agree. My suggestion would be
1) Split Bio.WWW.ExPASy (access to Swissprot, Prodoc, Prosite) between
Bio.SwissProt, Bio.Prosite, and Bio.Prodoc as appropriate
2) Put Bio.WWW.InterPro in Bio.InterPro
3) Put Bio.WWW.SCOP in Bio.SCOP
4) NCBI Entrez is a special case since it contains many different sorts of
data. Bio.GenBank doesn't seem to be the best place for it, as NCBI Entrez is
much more than GenBank. I would therefore suggest to move Bio.WWW.NCBI to
Bio.Entrez (currently an empty module in Biopython), and merge this code with
the database access code in Bio.GenBank and Bio.EUtils.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3245 bytes
Desc: not available
Url : http://lists.open-bio.org/pipermail/biopython-dev/attachments/20071113/0f9b5d9e/attachment.bin
From chris.lasher at gmail.com Tue Nov 13 23:01:55 2007
From: chris.lasher at gmail.com (Chris Lasher)
Date: Tue, 13 Nov 2007 23:01:55 -0500
Subject: [Biopython-dev] Biopython SVN Transition
In-Reply-To: <4739775A.1020208@maubp.freeserve.co.uk>
References: <128a885f0710300717p7d91a4adjfaddc9c496974e67@mail.gmail.com>
<47278655.8090300@maubp.freeserve.co.uk>
<128a885f0710302255y4c34ac8axa48f48b253d5854a@mail.gmail.com>
<4739775A.1020208@maubp.freeserve.co.uk>
Message-ID: <128a885f0711132001j3d4c7c3aj1c1e255c66acd634@mail.gmail.com>
On Nov 13, 2007 5:07 AM, Peter wrote:
> Chris Lasher wrote:
> >> In terms of timing, how long do you/the OBF guys expect the transfer to
> >> take? And would they prefer to do this over a weekend or mid week?
> >
> > Not sure, let me ask Jason Stajich.
> > ...
> > I think we could expect less than a full day downtime.
>
> Any preference on mid week versus weekend? I'm still happy with any time
> in the next fortnight.
I haven't gotten in touch with Jason on this. Let me see what works for him.
> >> P.S. Would you or any of the people doing the transition be able to sort
> >> out bug 2363?
> >> http://bugzilla.open-bio.org/show_bug.cgi?id=2363
> >
> > That's a very good question. I wonder if cvs2svn is capable of picking
> > up those errors in commits and choose the proper format. I had trouble
> > getting a hold of an expert who could tell me how to identify files
> > committed as binary files, and how to change that to text (or vice
> > versa). I should send an email to the Subversion mailing list,
> > perhaps, or the CVS list if it's still active. I'll also check to see
> > if Jason knows.
>
> If you can solve this, it would make life easier for building from
> source on Windows :)
cvs status actually reveals this--any item marked with the following
"""
Sticky Options: -kb
"""
Was checked in as binary. To un-binary it, I guess we remove this property.
Chris
From bugzilla-daemon at portal.open-bio.org Wed Nov 14 04:17:37 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 14 Nov 2007 04:17:37 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711140917.lAE9HbTO023884@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-14 04:17 EST -------
In an email Eric Gibert wrote:
> MySQL does not commit the transaction by default and autocommit
> is not so advisable to ensure the database integrity. Thus we
> could include a .adaptor.commit() at the end of the
> following functions:
>
> Loader.py: load_seqrecord and remove
> BioSeqDatabase: DBServer.remove_database, new_database, load_database_sql
> BioSeqDatabase.Load (which might be redundant with commit in Loader)
I had also been wondering about something like this.
However, We need to think about the other database engines not just MySQL. And
we need to think about how this would affect anyone trying to use SQL
transactions.
Also, doing a commit in Loader.py's load() method after all the records, might
be better than in load_seqrecord() after each record. That way we should load
either all the records or none. Otherwise if the process fails half way, we
would have only half the records commited and that would be more difficult for
the user to sort out.
--
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.
From mdehoon at c2b2.columbia.edu Wed Nov 14 04:35:29 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Wed, 14 Nov 2007 04:35:29 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu> <47396A11.8020705@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
<473AB8A6.3050200@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65F@mail2.exch.c2b2.columbia.edu>
> When you say move, do you mean just move - which will break existing
> scripts, or perhaps copy the stuff and mark the old version depreciated?
I was thinking to move the code itself, and let the function in the old
module call the function in the new module, after a DeprecationWarning.
> P.S. Is this sort of large scale rearrangement the sort of changes SVN
> is meant to track better than CVS?
Hopefully. One problem with CVS is that directories cannot be removed easily.
I hope that that will be easier with SVN.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From biopython-dev at maubp.freeserve.co.uk Wed Nov 14 03:58:14 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Wed, 14 Nov 2007 08:58:14 +0000
Subject: [Biopython-dev] Bio.WWW; database access
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu> <47396A11.8020705@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
Message-ID: <473AB8A6.3050200@maubp.freeserve.co.uk>
Michiel De Hoon wrote:
>> However, what about the fact that some online resources (e.g. GenBank)
>> will return several sorts of data (e.g. journal references and
>> sequences) and/or in a range of file formats (e.g. GenBank, Fasta, XML,
>> ...). In this situation, having the online interface separate from the
>> format parsers makes some sense.
>
> I agree. My suggestion would be
>
> 1) Split Bio.WWW.ExPASy (access to Swissprot, Prodoc, Prosite) between
> Bio.SwissProt, Bio.Prosite, and Bio.Prodoc as appropriate
> 2) Put Bio.WWW.InterPro in Bio.InterPro
> 3) Put Bio.WWW.SCOP in Bio.SCOP
> 4) NCBI Entrez is a special case since it contains many different sorts of
> data. Bio.GenBank doesn't seem to be the best place for it, as NCBI Entrez is
> much more than GenBank. I would therefore suggest to move Bio.WWW.NCBI to
> Bio.Entrez (currently an empty module in Biopython), and merge this code with
> the database access code in Bio.GenBank and Bio.EUtils.
>
> --Michiel.
That organisation sounds fine.
When you say move, do you mean just move - which will break existing
scripts, or perhaps copy the stuff and mark the old version depreciated?
P.S. Is this sort of large scale rearrangement the sort of changes SVN
is meant to track better than CVS?
Peter
From bugzilla-daemon at portal.open-bio.org Wed Nov 14 10:16:36 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 14 Nov 2007 10:16:36 -0500
Subject: [Biopython-dev] [Bug 2396] BioSQL loader does not store sequence
level annotations dict
In-Reply-To:
Message-ID: <200711141516.lAEFGaJI009957@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
------- Comment #2 from ericgibert at yahoo.fr 2007-11-14 10:16 EST -------
(From update of attachment 806)
I included the code provided in Loader.py and tested it successfully: 3 new
entries are now added to annotations after creation of a sequence from NCBI:
> 'source': ['mitochondrion Misagria parana '],
> 'sequence_version': ['1'] ,
> 'date': ['01-MAY-2006']
(curiously, we also have 'dates': ['01-MAY-2006']... ).
Anyway, this code seams quite good.
--
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.
From chris.lasher at gmail.com Thu Nov 15 15:39:15 2007
From: chris.lasher at gmail.com (Chris Lasher)
Date: Thu, 15 Nov 2007 15:39:15 -0500
Subject: [Biopython-dev] Biopython SVN Transition
In-Reply-To: <128a885f0711132001j3d4c7c3aj1c1e255c66acd634@mail.gmail.com>
References: <128a885f0710300717p7d91a4adjfaddc9c496974e67@mail.gmail.com>
<47278655.8090300@maubp.freeserve.co.uk>
<128a885f0710302255y4c34ac8axa48f48b253d5854a@mail.gmail.com>
<4739775A.1020208@maubp.freeserve.co.uk>
<128a885f0711132001j3d4c7c3aj1c1e255c66acd634@mail.gmail.com>
Message-ID: <128a885f0711151239m682ef82cnfb393241b2922468@mail.gmail.com>
On Nov 13, 2007 11:01 PM, Chris Lasher wrote:
> cvs status actually reveals this--any item marked with the following
> """
> Sticky Options: -kb
> """
>
> Was checked in as binary. To un-binary it, I guess we remove this property.
I found only four such files, at least under the Python code
directories of Biopython, and all were pickle files. So perhaps we
really don't have any files checked in as binary that shouldn't be?
Chris
From bugzilla-daemon at portal.open-bio.org Thu Nov 15 18:03:15 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 15 Nov 2007 18:03:15 -0500
Subject: [Biopython-dev] [Bug 2363] Some python files not stored as plain
text in CVS?
In-Reply-To:
Message-ID: <200711152303.lAFN3FDB032238@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2363
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |minor
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-15 18:03 EST -------
I think I've fixed some of these python files, having checked CVS stores them
as plain text, by correcting the newlines on Windows and committing the revised
version.
The unit tests affected seem OK now.
--
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.
From biopython-dev at maubp.freeserve.co.uk Sat Nov 17 17:33:41 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Sat, 17 Nov 2007 22:33:41 +0000
Subject: [Biopython-dev] Making mxTextTools an optional dependency in
setup.py
Message-ID: <320fb6e00711171433g2be36daatf7d8a64cad23d550@mail.gmail.com>
I'd like to update setup.py to make mxTextTools optional for
installing Biopython (the same status as ReportLab and Numeric). We
can still encourage people to install it for those part of Biopython
which do still use it, but I think a good proportion doesn't need it
anymore.
Any comments?
Peter
From mdehoon at c2b2.columbia.edu Sun Nov 18 20:23:06 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Sun, 18 Nov 2007 20:23:06 -0500
Subject: [Biopython-dev] Making mxTextTools an optional dependency
insetup.py
References: <320fb6e00711171433g2be36daatf7d8a64cad23d550@mail.gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B662@mail2.exch.c2b2.columbia.edu>
The fewer dependencies, the merrier; having two mxTextTools versions makes
this dependency even trickier. I am not sure though how much of Biopython
needs mxTextTools.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
-----Original Message-----
From: biopython-dev-bounces at lists.open-bio.org on behalf of Peter
Sent: Sat 11/17/2007 5:33 PM
To: BioPython Developers List
Subject: [Biopython-dev] Making mxTextTools an optional dependency insetup.py
I'd like to update setup.py to make mxTextTools optional for
installing Biopython (the same status as ReportLab and Numeric). We
can still encourage people to install it for those part of Biopython
which do still use it, but I think a good proportion doesn't need it
anymore.
Any comments?
Peter
_______________________________________________
Biopython-dev mailing list
Biopython-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biopython-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3373 bytes
Desc: not available
Url : http://lists.open-bio.org/pipermail/biopython-dev/attachments/20071118/93b7f64d/attachment.bin
From mdehoon at c2b2.columbia.edu Sun Nov 18 21:33:11 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Sun, 18 Nov 2007 21:33:11 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu> <47396A11.8020705@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
<473AB8A6.3050200@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65F@mail2.exch.c2b2.columbia.edu>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B663@mail2.exch.c2b2.columbia.edu>
In my local copy of Biopython, I have now moved the SCOP database access code
from Bio/WWW/SCOP.py to Bio/SCOP/__init__.py. This are the functions "search"
and "_open" (which is an internally used function), both of which will for
the time being also be available (with a deprecation warning) from
Bio.WWW.SCOP. Any final objections before I upload this to CVS?
When SCOP is done, I'll start on moving Bio.WWW.InterPro to Bio.InterPro.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 04:00:27 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 04:00:27 -0500
Subject: [Biopython-dev] [Bug 2403] New: prosite parser can't handle new
PROSITE/PRORULE format
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
Summary: prosite parser can't handle new PROSITE/PRORULE format
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Main Distribution
AssignedTo: biopython-dev at biopython.org
ReportedBy: holger.dinkel at gmail.com
Prosite introduced a new field called ProRules which cause errors
in parsing with Bio/Prosite/__init__.py / Bio/ParserSupport.py.
The error applies to 1.42 and 1.44.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 04:02:16 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 04:02:16 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711190902.lAJ92GHa022134@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #1 from holger.dinkel at gmail.com 2007-11-19 04:02 EST -------
Created an attachment (id=812)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=812&action=view)
Test-Case PROSITE.DAT to reproduce the error
This is the first couple of lines of a prosite.dat (version 20) with prorule
entries to reproduce the error...
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 04:04:23 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 04:04:23 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711190904.lAJ94Nsv022557@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #2 from holger.dinkel at gmail.com 2007-11-19 04:04 EST -------
Created an attachment (id=813)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=813&action=view)
script to demonstrate the error
This script tries to parse the attached 'prosite_test.dat' and produces the
described error.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 05:38:48 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 05:38:48 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711191038.lAJAcmhW026808@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |biopython-
| |bugzilla at maubp.freeserve.co.
| |uk
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 05:38 EST -------
Confirming bug, I'll take a look at this now.
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.
From biopython at maubp.freeserve.co.uk Mon Nov 19 05:44:17 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 10:44:17 +0000
Subject: [Biopython-dev] Next release (was re: bug 2993)
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B661@mail2.exch.c2b2.columbia.edu>
References: <8fc5e4c20711161326q27723a16re5eca3de82573f8e@mail.gmail.com> <320fb6e00711161338w73f8e7d1l964671208e263ba3@mail.gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B661@mail2.exch.c2b2.columbia.edu>
Message-ID: <47416901.1070204@maubp.freeserve.co.uk>
Michiel De Hoon wrote:
> It's probably a good idea to make a new Biopython release in the near
> future, after fixing this bug [2393, Bio.GenBank.NCBIDictionary fails
> with release 1.44].
I would agree another release would be a good idea - but did you mean
you wanted to "fix" bug 2393 by avoiding Bio.config.DBRegistry, or just
go with my "one line fix" for now?
We should also check what state Tiago's Coalescent support through
Simcoal2 is at: http://bugzilla.open-bio.org/show_bug.cgi?id=2375
And, do you want to "tidy" up Bio.WWW before or after this new release?
I would vote for before - but we can add a warning to the release notes
that this is coming.
Peter
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 06:40:34 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 06:40:34 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711191140.lAJBeYGG030123@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #4 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 06:40 EST -------
Fixed in CVS, and I've also updated the unit test. Having the test data file
and example script all ready made this much easier, thanks.
As per my email, the order in _scan_fns does matter. The 'redundancy' you
spotted was commented as an ugly hack.
P.S. I would have used the following style in your script:
handle = open(PROSITEDAT)
iterator = Iterator(handle,RecordParser())
for record in iterator :
print record.name
prosite_data.append(record)
handle.close()
rather than:
handle = open(PROSITEDAT)
iterator = Iterator(handle,RecordParser())
record = iterator.next()
prosite_data = []
while record:
print record.name
prosite_data.append(record)
record = iterator.next()
handle.close()
--
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.
From tiagoantao at gmail.com Mon Nov 19 10:00:38 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Mon, 19 Nov 2007 15:00:38 +0000
Subject: [Biopython-dev] Accessing built-in data files
Message-ID: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
Hi,
The following mail documents my effort in understanding what needs to
be done in order to include data files with biopython. This serves to
purposes:
1. For review by others
2. For future reference, to anyone that needs to package data with the
distribution.
The problem can be split into 2 parts
1. Including the data with the distribution
2. Accessing the data that was packaged
The second is more complicated than the first.
1. Including the data with the distribution
Biopython uses distutils, a standard Python package mechanism. To
include data files, setup.py needs to be changed.
I recommend reading chapter 2 of the distutils manual
http://docs.python.org/dist/dist.html . Especially "Installing Package
Data" and "Installing Additional Files". I am using the "Package Data"
part.
In this scenario, the data files are placed alongside with the code in
the code directory (or, best, in a data subdirectory below).
To make this work setup.py needs to be changed. The change seems to be
trivial: Go to DATA_FILES and include your files. For SimCoal I did
this:
DATA_FILES=[
#.... More stuff will be here for other packages
"Bio/PopGen/SimCoal/data/*par" #my data files are *par
]
Thats it! Of course, as usual, the package should have been added (but
that is true to all packages)
2. Accessing the data that was packaged
This one is trickier. The first problem is that the data files might
be installed in either the platform dependent install directory or in
the platform independent one. With biopython this is actually a
non-problem, as data seems to go to the platform independent
directory. Which I suppose is the correct thing to do.
Now, the typical strategy is to get the sys.prefix to get the
directory where the platform independent files are installed (really
bad would be to get sys.exec_prefix which gets the platform dependent
path) and to append the package specific part. The problem is that, in
some cases (e.g. typical development cycle or when one doesn't have
admin install privileges on the computer), the installation is done to
another directory other than the system-wide default. My work around?
Go through all the directories on sys.path (PYTHONPATH) and search for
a data file that I know is there (because we know the path relative to
root of the installation, as on DATA_FILES above). When that file is
found, then the directory where all stuff is, is found. Not perfect,
but works for now.
Here is possible code to go to, e.g., __init__.py, of a package (based
on my SimCoal example):
---CODE STARTS---
from os import sep
from sys import path
for entry in path:
try:
#Searching for a single case, to determine correct directory
try_path = sep.join([entry, 'Bio', 'PopGen', 'SimCoal', 'data',
'island.par'])
f = open(try_path)
builtin_template_path = try_path
del try_path
f.close()
break
except:
pass #Correct behavior, searching for entry
---CODE ENDS---
One could raise an error if not found.
Comments?
Regards,
Tiago
--
http://www.tiago.org/ps
From biopython at maubp.freeserve.co.uk Mon Nov 19 10:25:48 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 15:25:48 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
Message-ID: <4741AAFC.70304@maubp.freeserve.co.uk>
Tiago Ant?o wrote:
> 1. Including the data with the distribution
> Biopython uses distutils, a standard Python package mechanism. To
> include data files, setup.py needs to be changed. ...
> Go to DATA_FILES and include your files. For SimCoal I did
> this:
> DATA_FILES=[
> #.... More stuff will be here for other packages
> "Bio/PopGen/SimCoal/data/*par" #my data files are *par
> ]
> Thats it! Of course, as usual, the package should have been added (but
> that is true to all packages)
Good.
> 2. Accessing the data that was packaged
> This one is trickier. The first problem is that the data files might
> be installed in either the platform dependent install directory or in
> the platform independent one. ...
I may be naive here, but I would expect the datafiles to be installed in
the same relative path as the python files. Is this not always the case?
As I pointed out in bug 2375, there is some code in setup.py (pre-dating
the support in distutils) which takes care of installing data files for
EUtils - if that actually works for the special cases you are concerned
about, maybe we should just use that for your data files too. See
http://bugzilla.open-bio.org/show_bug.cgi?id=2375
> My work around? Go through all the directories on sys.path (PYTHONPATH) and search for
> a data file that I know is there ...
That doesn't seem very elegant :(
Peter
From tiagoantao at gmail.com Mon Nov 19 10:41:57 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Mon, 19 Nov 2007 15:41:57 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <4741AAFC.70304@maubp.freeserve.co.uk>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
<4741AAFC.70304@maubp.freeserve.co.uk>
Message-ID: <6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
On Nov 19, 2007 3:25 PM, Peter wrote:
> > 2. Accessing the data that was packaged
> > This one is trickier. The first problem is that the data files might
> > be installed in either the platform dependent install directory or in
> > the platform independent one. ...
>
> I may be naive here, but I would expect the datafiles to be installed in
> the same relative path as the python files. Is this not always the case?
Yep, but which datafiles and where? By which I mean, platform
dependent or platform independent. Again this is mainly a not issue.
But "where" is important. "Where" might be the system path and all is
fine and dandy, but it also might be elsewhere (In my case, when
testing I don't install to the system path. Also, if you don't have
admin access to the machine...)
>
> As I pointed out in bug 2375, there is some code in setup.py (pre-dating
> the support in distutils) which takes care of installing data files for
> EUtils - if that actually works for the special cases you are concerned
> about, maybe we should just use that for your data files too. See
> http://bugzilla.open-bio.org/show_bug.cgi?id=2375
I checked that. I don't think (as far as I researched) that the data
is really accessed at execution.
DTDs (you can check the DTDs directory inside EUtils) were converted
to py files. And the data directory is actually a python module
directory (the generated py code is on CVS, actually).
> > My work around? Go through all the directories on sys.path (PYTHONPATH) and search for
> > a data file that I know is there ...
>
> That doesn't seem very elegant :(
I know, that is one of the reasons I called it "work around" and I am
discussing this in the open.
The changes to setup.py are quite trivial and pacific. But at the code
level I cannot think of a better solution. All that occurs to me is:
1. Use sys.prefix. Clean but that would mean only installations to the
system directory. I don't think that that is acceptable
2. The current solution
3. If there was a way to know where the package code is installed, I
could infer the data directory from there (clean, precise and robust),
but I don't know how to do that (if there is a way at all). That would
sort things out.
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 10:54:32 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 10:54:32 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711191554.lAJFsWf7015661@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #18 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 10:54 EST -------
Marking as fixed - using CVS this now works for me with MySQL (subject to
manually doing a commit as per bug 2396).
P.S. There was a cut and past error in my sample code in comment 15, note that
Bio.SeqIO just wraps the Bio.SwissProt parser so this is pretty much equivalent
to Jon's original example.
#Run this in the Biopython/Tests/SwissProt directory
from BioSQL import BioSeqDatabase
from Bio import SeqIO
import os
server = BioSeqDatabase.open_database(driver='MySQLdb', user='root', passwd='',
host='localhost', db='bioseqdb')
db = server.new_database('bug2390')
for filename in os.listdir(".") :
if filename[:2]=="sp" :
print "Loading %s" % filename
db.load(SeqIO.parse(open(filename), "swiss"))
print "Committing..."
server.adaptor.commit()
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 10:59:37 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 10:59:37 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711191559.lAJFxbqK016012@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #8 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 10:59 EST -------
Do you want to mark this bug as fixed (with the one line import change), and
tackle rationalising Bio.config.DBRegistry, Bio.WWW etc separately?
Are you happy for me to check in that suggested unit test?
(test_SeqIO_online.py - attachment 805 on this bug)
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From tiagoantao at gmail.com Mon Nov 19 11:05:13 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Mon, 19 Nov 2007 16:05:13 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <4741B12E.9070909@maubp.freeserve.co.uk>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
<4741AAFC.70304@maubp.freeserve.co.uk>
<6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
<4741B12E.9070909@maubp.freeserve.co.uk>
Message-ID: <6d941f120711190805i5aa68392k62598d787567f079@mail.gmail.com>
> If the data files are installed the data subdirectory of where your
> python are, can't your python files just load them using a relative path?
Relative to what? The current directory is where the user is (not the
biopython directory). I don't know where the biopython code is (read
below), as such I cannot compute a path relative to it.
> Am I missing something?
The question is: How do I determine where biopython is installed? Is
that possible from inside the running code, in runtime? If yes, then
all is sorted (I just don't know how to do that), if no then I can
only think of transversing the whole PYTHONPATH.
Yes, it should be relative to the code path - I agree with you. But
how one finds where the code is (from a bunch of possible
alternatives) in runtime?
--
http://www.tiago.org/ps
From tiagoantao at gmail.com Mon Nov 19 11:42:46 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Mon, 19 Nov 2007 16:42:46 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <4741B8CD.1020103@maubp.freeserve.co.uk>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
<4741AAFC.70304@maubp.freeserve.co.uk>
<6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
<4741B12E.9070909@maubp.freeserve.co.uk>
<6d941f120711190805i5aa68392k62598d787567f079@mail.gmail.com>
<4741B8CD.1020103@maubp.freeserve.co.uk>
Message-ID: <6d941f120711190842y757b8d64m1516d82b185bf6d@mail.gmail.com>
> I think the answer is python's __file__ which will give the filename of
> the module (relative to the current working directory it would seem).
Spot on, thanks
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 11:57:43 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 11:57:43 -0500
Subject: [Biopython-dev] [Bug 19] implement dbsearch Registry
In-Reply-To:
Message-ID: <200711191657.lAJGvhkO020116@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=19
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|jchang at biopython.org |biopython-dev at biopython.org
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 11:57 EST -------
Should we mark this very old bug as a "won't fix"?
Or could someone explain in more detail what the plan here was?
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 12:22:16 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 12:22:16 -0500
Subject: [Biopython-dev] [Bug 1987] Alphabet.Gapped does not retain gap
character
In-Reply-To:
Message-ID: <200711191722.lAJHMGls021340@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=1987
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 12:22 EST -------
Having thought about this on and off for a while, I can't see any reason not to
deal with this bug. Fixed in CVS, Bio/Alphabet/__init__.py revision 1.7
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 12:28:13 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 12:28:13 -0500
Subject: [Biopython-dev] [Bug 1982] Patch to BioSQL/Loader.py
In-Reply-To:
Message-ID: <200711191728.lAJHSDQw021855@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=1982
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #4 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 12:28 EST -------
Given this was checked in months ago, with no new comments, I'm marking this as
fixed.
Note that earlier today I updated BioSQL to retrieve the db_xref data for
SeqFeatures from the database - the old code only stored this information in
the databse.
--
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.
From biopython at maubp.freeserve.co.uk Mon Nov 19 10:52:14 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 15:52:14 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com> <4741AAFC.70304@maubp.freeserve.co.uk>
<6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
Message-ID: <4741B12E.9070909@maubp.freeserve.co.uk>
Tiago Ant?o wrote:
>> I may be naive here, but I would expect the datafiles to be installed in
>> the same relative path as the python files. Is this not always the case?
>
> Yep, but which datafiles and where? By which I mean, platform
> dependent or platform independent. Again this is mainly a not issue.
> But "where" is important. "Where" might be the system path and all is
> fine and dandy, but it also might be elsewhere (In my case, when
> testing I don't install to the system path. Also, if you don't have
> admin access to the machine...)
If the data files are installed the data subdirectory of where your
python are, can't your python files just load them using a relative path?
e.g. On Windows, using Python 2.3 (from memory) the files should go:
C:\Python23\lib\site-packages\Bio\PopGen\SimCoal\*.py
C:\Python23\lib\site-packages\Bio\PopGen\SimCoal\data\*.par
On my linux machine, where I have installed Biopython under my home
directory (rather than system wide):
~/lib/python2.4/site-packages/Bio/PopGen/SimCoal/*.py
~/lib/python2.4/site-packages/Bio/PopGen/SimCoal/data/*.par
If I had installed Biopython using admin access, it might be:
/usr/lib/python2.4/site-packages/Bio/PopGen/SimCoal/*.py
/usr/lib/python2.4/site-packages/Bio/PopGen/SimCoal/data/*.par
In all those cases, one of your SimCoal python files just needs to open
its data files using a relative path, for example "data/island.par".
For comparison, the EUtils DTD files did end up here as I expected:
~/lib/python2.4/site-packages/Bio/EUtils/DTDs/*.dtd
Am I missing something?
Peter
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 19:51:28 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 19:51:28 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711200051.lAK0pShp012213@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #9 from mdehoon at ims.u-tokyo.ac.jp 2007-11-19 19:51 EST -------
> Do you want to mark this bug as fixed (with the one line import change), and
> tackle rationalising Bio.config.DBRegistry, Bio.WWW etc separately?
I'd leave this bug open for now, since the one line import change causes a
DeprecationWarning. Treating the rationalisation of Bio.config.DBRegistry,
Bio.WWW etc as a separate issue is fine with me. Once we have a solution for
that, fixing Bio.GenBank.NCBIDictionary will be trivial.
> Are you happy for me to check in that suggested unit test?
> (test_SeqIO_online.py - attachment 805 [details] on this bug)
That is fine with me.
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 19:52:19 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 19:52:19 -0500
Subject: [Biopython-dev] [Bug 19] implement dbsearch Registry
In-Reply-To:
Message-ID: <200711200052.lAK0qJFe012265@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=19
------- Comment #2 from mdehoon at ims.u-tokyo.ac.jp 2007-11-19 19:52 EST -------
"won't fix" sounds reasonable to me.
--
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.
From mdehoon at c2b2.columbia.edu Mon Nov 19 19:53:41 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Mon, 19 Nov 2007 19:53:41 -0500
Subject: [Biopython-dev] Next release (was re: bug 2993)
References: <8fc5e4c20711161326q27723a16re5eca3de82573f8e@mail.gmail.com> <320fb6e00711161338w73f8e7d1l964671208e263ba3@mail.gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B661@mail2.exch.c2b2.columbia.edu>
<47416901.1070204@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B665@mail2.exch.c2b2.columbia.edu>
> Michiel De Hoon wrote:
> > It's probably a good idea to make a new Biopython release in the near
> > future, after fixing this bug [2393, Bio.GenBank.NCBIDictionary fails
> > with release 1.44].
>
> I would agree another release would be a good idea - but did you mean
> you wanted to "fix" bug 2393 by avoiding Bio.config.DBRegistry, or just
> go with my "one line fix" for now?
The "one line fix" is OK for current users of Biopython 1.44, but since it
generates a DeprecationWarning I think it should not go into the next
release.
> And, do you want to "tidy" up Bio.WWW before or after this new release?
> I would vote for before - but we can add a warning to the release notes
> that this is coming.
I'd like to tidy up Bio.WWW before.
> We should also check what state Tiago's Coalescent support through
> Simcoal2 is at: http://bugzilla.open-bio.org/show_bug.cgi?id=2375
I expect that it will take a couple of weeks to tidy up Bio.WWW et al., so
hopefully there will be enough time for Tiago's Coalescent support to be
finished on time for the next release.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 20:31:17 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 20:31:17 -0500
Subject: [Biopython-dev] [Bug 19] implement dbsearch Registry
In-Reply-To:
Message-ID: <200711200131.lAK1VHqU014193@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=19
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 20:31 EST -------
Resolving as "Won't Fix"
--
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.
From biopython at maubp.freeserve.co.uk Mon Nov 19 09:05:23 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 14:05:23 +0000
Subject: [Biopython-dev] BioSQL
Message-ID: <47419823.8040305@maubp.freeserve.co.uk>
Dear list members,
As some of you may have guessed from recent bug activity, I've got
BioSQL up and running on my machine, using MySQL. I've even made a
start at updating the documentation:
http://www.biopython.org/wiki/BioSQL
Annoyingly the unit test (test_BioSQL.py) wasn't working, but I believe
that I have fixed that now in CVS. If any of the other developers have
BioSQL setup, could you please check out the latest code and double
check this for me. If you use something other than MySQL that would be
of particular interest.
Also, comments on the MySQL commit issue in Bug 2395 welcome!
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
Peter
P.S. I've not yet sorted out bug 2396, I want to study how BioPerl
and/or BioJava handle this to make sure what ever I do is compatible.
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
From mdehoon at c2b2.columbia.edu Mon Nov 19 21:34:09 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Mon, 19 Nov 2007 21:34:09 -0500
Subject: [Biopython-dev] BioSQL
References: <47419823.8040305@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
With the Biopython currently in CVS, I get an error from test_BioSQL:
======================================================================
FAIL: test_BioSQL
----------------------------------------------------------------------
Traceback (most recent call last):
File "run_tests.py", line 151, in runTest
self.runSafeTest()
File "run_tests.py", line 188, in runSafeTest
expected_handle)
File "run_tests.py", line 289, in compare_output
"\nOutput : "+`output_line` + "\nExpected: "+`expected_line`
AssertionError:
Output : 'Load SeqRecord objects into a BioSQL database. ... ERROR\n'
Expected: 'Load SeqRecord objects into a BioSQL database. ... ok\n'
----------------------------------------------------------------------
If I run test_BioSQL.py directly, I expect to get a
Bio.MissingExternalDependencyError (as with Biopython 1.44):
Traceback (most recent call last):
File "test_BioSQL.py", line 40, in
raise Bio.MissingExternalDependencyError(message)
Bio.MissingExternalDependencyError: Enable tests in Tests/test_BioSQL.py (not
im
portant if you do not plan to use BioSQL).
---------------------------------------------------------------------------
With Biopython now in CVS, test_BioSQL.py generates the following output:
$ python test_BioSQL.py
Load SeqRecord objects into a BioSQL database. ... ERROR
Get a list of all items in the database. ... ERROR
Test retrieval of items using various ids. ... ERROR
Make sure Seqs from BioSQL implement the right interface. ... ERROR
Check SeqFeatures of a sequence. ... ERROR
Make sure SeqRecords from BioSQL implement the right interface. ... ERROR
Check that slices of sequences are retrieved properly. ... ERROR
Make sure all records are correctly loaded. ... ERROR
Indepth check that SeqFeatures are transmitted through the db. ... ERROR
======================================================================
ERROR: Load SeqRecord objects into a BioSQL database.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 275, in setUp
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Get a list of all items in the database.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 128, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Test retrieval of items using various ids.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 128, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Make sure Seqs from BioSQL implement the right interface.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 179, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Check SeqFeatures of a sequence.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 179, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Make sure SeqRecords from BioSQL implement the right interface.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 179, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Check that slices of sequences are retrieved properly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 179, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Make sure all records are correctly loaded.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 329, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Indepth check that SeqFeatures are transmitted through the db.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 329, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
----------------------------------------------------------------------
Ran 9 tests in 0.140s
FAILED (errors=9)
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
-----Original Message-----
From: biopython-dev-bounces at lists.open-bio.org on behalf of Peter
Sent: Mon 11/19/2007 9:05 AM
To: biopython-dev at lists.open-bio.org
Subject: [Biopython-dev] BioSQL
Dear list members,
As some of you may have guessed from recent bug activity, I've got
BioSQL up and running on my machine, using MySQL. I've even made a
start at updating the documentation:
http://www.biopython.org/wiki/BioSQL
Annoyingly the unit test (test_BioSQL.py) wasn't working, but I believe
that I have fixed that now in CVS. If any of the other developers have
BioSQL setup, could you please check out the latest code and double
check this for me. If you use something other than MySQL that would be
of particular interest.
Also, comments on the MySQL commit issue in Bug 2395 welcome!
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
Peter
P.S. I've not yet sorted out bug 2396, I want to study how BioPerl
and/or BioJava handle this to make sure what ever I do is compatible.
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
_______________________________________________
Biopython-dev mailing list
Biopython-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biopython-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5527 bytes
Desc: not available
Url : http://lists.open-bio.org/pipermail/biopython-dev/attachments/20071119/d8b82983/attachment-0001.bin
From biopython at maubp.freeserve.co.uk Mon Nov 19 11:24:45 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 16:24:45 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <6d941f120711190805i5aa68392k62598d787567f079@mail.gmail.com>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com> <4741AAFC.70304@maubp.freeserve.co.uk> <6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com> <4741B12E.9070909@maubp.freeserve.co.uk>
<6d941f120711190805i5aa68392k62598d787567f079@mail.gmail.com>
Message-ID: <4741B8CD.1020103@maubp.freeserve.co.uk>
Tiago Ant?o wrote:
>> If the data files are installed the data subdirectory of where your
>> python are, can't your python files just load them using a relative path?
>
> Relative to what? The current directory is where the user is (not the
> biopython directory). I don't know where the biopython code is (read
> below), as such I cannot compute a path relative to it.
>
> ...
>
> Yes, it should be relative to the code path - I agree with you. But
> how one finds where the code is (from a bunch of possible
> alternatives) in runtime?
I think the answer is python's __file__ which will give the filename of
the module (relative to the current working directory it would seem).
Peter
From sbassi at gmail.com Mon Nov 19 22:43:03 2007
From: sbassi at gmail.com (Sebastian Bassi)
Date: Tue, 20 Nov 2007 00:43:03 -0300
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <4741B12E.9070909@maubp.freeserve.co.uk>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
<4741AAFC.70304@maubp.freeserve.co.uk>
<6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
<4741B12E.9070909@maubp.freeserve.co.uk>
Message-ID:
On Nov 19, 2007 12:52 PM, Peter wrote:
> e.g. On Windows, using Python 2.3 (from memory) the files should go:
> C:\Python23\lib\site-packages\Bio\PopGen\SimCoal\*.py
...
That is the default option in Windows. But the installer gives the
user the choice to change the installation path.
--
Curso Biologia Molecular para programadores: http://tinyurl.com/2vv8w6
Bioinformatics news: http://www.bioinformatica.info
Lriser: http://www.linspire.com/lraiser_success.php?serial=318
From mdehoon at c2b2.columbia.edu Tue Nov 20 03:39:53 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 20 Nov 2007 03:39:53 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu> <47396A11.8020705@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
<473AB8A6.3050200@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65F@mail2.exch.c2b2.columbia.edu>
<6243BAA9F5E0D24DA41B27997D1FD14402B663@mail2.exch.c2b2.columbia.edu>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B668@mail2.exch.c2b2.columbia.edu>
Hi everybody,
I have now moved the database access code from Bio.WWW.SCOP and
Bio.WWW.InterPro to Bio.SCOP and Bio.InterPro, respectively.
This leaves us with Bio.WWW.NCBI and Bio.WWW.ExPASy.
The latter contains the following functions:
get_prodoc_entry Interface to the get-prodoc-entry CGI script.
get_prosite_entry Interface to the get-prosite-entry CGI script.
get_sprot_raw Interface to the get-sprot-raw.pl CGI script.
sprot_search_ful Interface to the sprot-search-ful CGI script.
sprot_search_de Interface to the sprot-search-de CGI script.
so it access Prodoc, Prosite, and SwissProt.
The corresponding parsers are in
Bio.Prosite.Prodoc for Prodoc
Bio.Prosite for Prosite
Bio.SwissProt.SProt for SwissProt
(each of these modules also contain some code to access Prodoc, Prosite,
SwissProt over the internet).
My question is: What is the preferred place to put the five functions from
Bio.WWW.ExPASy?
One option is to put get_prodoc_entry in Bio.Prosite.Prodoc,
get_prosite_entry in Bio.Prosite, and get_sprot_raw, sprot_search_ful, and
sprot_search_de in Bio.SwissProt.SProt (actually, I don't understand why we
have a Bio.SwissProt.SProt, since Bio.SwissProt.__init__ is currently empty,
but that's a different issue).
A second option is to have a separate Bio.ExPASy, so to simply rename
Bio.WWW.ExPAsy to Bio.ExPASy.
Any other options I haven't thought of?
I am leaning towards the first option. Any other opinions?
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From biopython-dev at maubp.freeserve.co.uk Tue Nov 20 05:13:35 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Tue, 20 Nov 2007 10:13:35 +0000
Subject: [Biopython-dev] BioSQL
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
References: <47419823.8040305@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
Message-ID: <320fb6e00711200213n5d78759bra006289f55a65992@mail.gmail.com>
Michiel De Hoon wrote:
> With the Biopython currently in CVS, I get an error from test_BioSQL:
Good point, I didn't try out the situation when the database wasn't
setup correctly.
> FAIL: test_BioSQL
> ...
> If I run test_BioSQL.py directly, I expect to get a
> Bio.MissingExternalDependencyError (as with Biopython 1.44):
> ...
> File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
> File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
> __bootstrap__
> ImportError: Permission denied
I moved the password setup etc out of test_BioSQL.py into
setup_BioSQL.py (two reasons, one I didn't want to have to check
test_BioSQL.py was up to date by hand, and two, I plan to add more tests).
I guess the problem is the default settings I put in setup_BioSQL.py,
which previously were undefined. These settings work for me, as
described on http://www.bioperl.org/wiki/BioSQL (new).
On your system, I guess that MySQL is available but the
username/password are wrong. If we revert these to being undefined,
then the test should fail as before with MissingExternalDependencyError.
Can you check that easily? I should probably add an error handler to
look for permission denied too...
Peter
From mdehoon at c2b2.columbia.edu Tue Nov 20 05:26:02 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 20 Nov 2007 05:26:02 -0500
Subject: [Biopython-dev] BioSQL
References: <47419823.8040305@maubp.freeserve.co.uk><6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
<320fb6e00711200213n5d78759bra006289f55a65992@mail.gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B669@mail2.exch.c2b2.columbia.edu>
> On your system, I guess that MySQL is available but the
> username/password are wrong. If we revert these to being undefined,
> then the test should fail as before with MissingExternalDependencyError.
>
> Can you check that easily? I should probably add an error handler to
> look for permission denied too...
If I comment out DBDRIVER and DBTYPE in setup_BioSQL.py, then the test fails
with a MissingExternalDependencyError as before.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From biopython-dev at maubp.freeserve.co.uk Tue Nov 20 05:29:43 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Tue, 20 Nov 2007 10:29:43 +0000
Subject: [Biopython-dev] BioSQL
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B669@mail2.exch.c2b2.columbia.edu>
References: <47419823.8040305@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
<320fb6e00711200213n5d78759bra006289f55a65992@mail.gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B669@mail2.exch.c2b2.columbia.edu>
Message-ID: <320fb6e00711200229m2af30809qc33c26d5bcfb14ed@mail.gmail.com>
> If I comment out DBDRIVER and DBTYPE in setup_BioSQL.py, then the test fails
> with a MissingExternalDependencyError as before.
Great. I'll fix that in CVS then. Can you configure things to
actually run the test?
Peter
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 07:30:51 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 07:30:51 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201230.lAKCUpXl017247@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #5 from holger.dinkel at gmail.com 2007-11-20 07:30 EST -------
Created an attachment (id=816)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=816&action=view)
fixed version (but with little hack; might not suit everybody)
There are still some errors thrown when scanning the whole prosite_20.dat:
Firstly, the Prosite-Team had also introduced a new field called
"postprocessing", so now the parser chokes on that.
And secondly the parser breaks at some special comment-lines with authornames
in it of the form "CC /AUTHOR=K_Hofmann; N_Hulo" (Prosite-Acc PS50293): The
comments are split into columns and then parsed into values at the
"="-letter. As Mr. Hulo does not have a "/Author=" prepended, an error is
raised...
I was able to fix the first problem straightforward as Peter did and inserted a
postprocessing-entry.
I could also solve the second problem, but only with some hack which might not
suit everybody:
First, i split the "qual, data = [word.lstrip() for word in col.split("=")]"
into two to avoid KeyErrors:
qual = [word.lstrip() for word in col.split("=")][0]
data = ''.join([word.lstrip() for word in col.split("=")][1:])
and then i introduced a hack to circumvent the aforementioned problem:
changed
if qual == '/TAXO-RANGE':
to
if qual == 'N_Hulo':
continue
elif qual == '/TAXO-RANGE':
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 07:33:14 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 07:33:14 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201233.lAKCXEGj017547@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #6 from holger.dinkel at gmail.com 2007-11-20 07:33 EST -------
Created an attachment (id=817)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=817&action=view)
patch with changes (but with little hack; might not suit everybody)
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 07:39:46 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 07:39:46 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201239.lAKCdkmx018187@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Comment #7 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-20 07:39 EST -------
Reopening bug.
Issue One:
PR lines (prorules), fixed.
Issue Two:
PP lines (post-processing)
See http://www.expasy.ch/prosite/psrelnot.html
Issue Three:
Funny CC lines, e.g. "CC /AUTHOR=K_Hofmann; N_Hulo" (Prosite-Acc PS50293)
See http://expasy.org/cgi-bin/get-prosite-raw.pl?PS50293
--
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.
From tiagoantao at gmail.com Tue Nov 20 07:42:36 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Tue, 20 Nov 2007 12:42:36 +0000
Subject: [Biopython-dev] Next release (was re: bug 2993)
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B665@mail2.exch.c2b2.columbia.edu>
References: <8fc5e4c20711161326q27723a16re5eca3de82573f8e@mail.gmail.com>
<320fb6e00711161338w73f8e7d1l964671208e263ba3@mail.gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B661@mail2.exch.c2b2.columbia.edu>
<47416901.1070204@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B665@mail2.exch.c2b2.columbia.edu>
Message-ID: <6d941f120711200442i39ad6908ped89b8d1bd822fbd@mail.gmail.com>
On Nov 20, 2007 12:53 AM, Michiel De Hoon wrote:
> > We should also check what state Tiago's Coalescent support through
> > Simcoal2 is at: http://bugzilla.open-bio.org/show_bug.cgi?id=2375
>
> I expect that it will take a couple of weeks to tidy up Bio.WWW et al., so
> hopefully there will be enough time for Tiago's Coalescent support to be
> finished on time for the next release.
I will prioritize this in my task list in order to have it ready on
time. I don't expect any serious problems.
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 08:29:41 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 08:29:41 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201329.lAKDTfDV020505@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #8 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-20 08:29 EST -------
Issue Two:
I've found an example with a PP line to test with, PS51192
http://expasy.org/cgi-bin/get-prosite-raw.pl?PS51192
Issue Three:
I think I've fixed the funny CC line problem with Bio/Prosite/__init__.py CVS
revision 1.15
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 08:39:34 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 08:39:34 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201339.lAKDdYRO021027@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #9 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-20 08:39 EST -------
Issue Two:
The PP lines problem should be fixed with with Bio/Prosite/__init__.py CVS
revision 1.15
Your patch was pretty close, you seem to have more or less understood how this
parser works :)
One problem I did notice was:
+ def _scan_pp(self, uhandle, consumer):
+ #New PP line, PostProcessing
+ self._scan_line('PP', uhandle, consumer.prorule, any_number=1)
Should have been:
+ def _scan_pp(self, uhandle, consumer):
+ #New PP line, PostProcessing
+ self._scan_line('PP', uhandle, consumer.postprocessing, any_number=1)
Otherwise any PP lines would get treated like PR lines!
Could you get the latest code, and confirm this works prosite.dat (version 20)?
There may be other quirks as I have only tried a few ProSite files myself...
Thank you, 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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 09:05:27 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 09:05:27 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201405.lAKE5RFA022593@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
holger.dinkel at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |holger.dinkel at gmail.com
Status|REOPENED |RESOLVED
Resolution| |FIXED
------- Comment #10 from holger.dinkel at gmail.com 2007-11-20 09:05 EST -------
Tested and confirmed.
Rev 1.16 of biopython/Bio/Prosite/__init__.py seems to work (tested on Prosite
V18-20) - at least it throws no exceptions ;->
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 13:49:32 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 13:49:32 -0500
Subject: [Biopython-dev] [Bug 2405] New: BioSQL gives UserWarning: ... not
recognised as database type: temporarily accepting key
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2405
Summary: BioSQL gives UserWarning: ... not recognised as database
type: temporarily accepting key
Product: Biopython
Version: 1.44
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
This can be demonstrated by the new unit test:
$python run_tests.py test_BioSQL_SeqIO.py
The test should pass, but prints lots of warnings to the console, e.g.:
.../BioSQL/Loader.py:500: UserWarning: LocusID not recognised as database type:
temporarily accepting key
warnings.warn("%s not recognised as database type: temporarily accepting key"
% key)
We need to update the dictionary (which is now) in BioSQL/__init__.py to cope
with these - but whatever mapping we use should be compatible with BioPerl,
BioJava, etc.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 17:50:29 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 17:50:29 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711202250.lAKMoTNg019776@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-20 17:50 EST -------
I'm begining to think this isn't a bug, its just a fact of life when dealing
with transactional databases - functionality that early versions of MySQL
lacked.
Either the user takes charge of the transactions, committing changes when they
see fit (e.g. after loading a file), or we enable auto-commit, or Biopython
trys to decide on its own - which risks getting it wrong. My current
preference is for explicit commits rather than implicit commits.
Comments welcome - especially from anyone using another database engine (e.g.
PostgreSQL)
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 21:53:21 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 21:53:21 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711210253.lAL2rLEX000301@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
------- Comment #4 from ericgibert at yahoo.fr 2007-11-20 21:53 EST -------
Although I agree on principle that this is not a bug, I think that we should
look what BioPerl and BioJava are doing. In my experience, BioJava does commit
transactions (that is why I was "surprised" in the first place :-) )
This being said, I do not mind adding commits...
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 21 13:20:38 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 21 Nov 2007 13:20:38 -0500
Subject: [Biopython-dev] [Bug 2408] New: GenBank records do not contain U's
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2408
Summary: GenBank records do not contain U's
Product: Biopython
Version: 1.43
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Main Distribution
AssignedTo: biopython-dev at biopython.org
ReportedBy: marcin.cieslik at gmail.com
The GenBank GenBank.FeatureParser() assigns a wrong alphabet for ss-RNA
records:
all GenBank records use T's not U's:
http://www.bioperl.org/pipermail/bioperl-l/2001-October/006400.html
parsing of:
http://www.ncbi.nlm.nih.gov/entrez/viewer.fcgi?db=nuccore&id=511859
results in:
u'511859': SeqRecord(seq=Seq('CAC <> TGG', IUPACAmbiguousRNA()),
id='M23021.1', name='MSBMVCCG', description='Southern cowpea mosaic virus,
complete genome.', dbxrefs=[])}
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 21 19:25:15 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 21 Nov 2007 19:25:15 -0500
Subject: [Biopython-dev] [Bug 2408] GenBank records do not contain U's
In-Reply-To:
Message-ID: <200711220025.lAM0PFTu026818@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2408
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-21 19:25 EST -------
So the GenBank file says in its header "ss-RNA" (single stranded RNA), and we
obey this and set an RNA alphabet. However, as you point out, the actual
sequence contains T not U, so is in fact given as DNA!
Is this a bug in GenBank maybe...?
Do you think we should switch the T's into U's to match the stated alphabet, or
simply return a DNA sequence based on the content?
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 22 00:18:03 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 22 Nov 2007 00:18:03 -0500
Subject: [Biopython-dev] [Bug 2408] GenBank records do not contain U's
In-Reply-To:
Message-ID: <200711220518.lAM5I3rX003480@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2408
------- Comment #2 from marcin.cieslik at gmail.com 2007-11-22 00:18 EST -------
I don't believe there are any U-containing records in GenBank since it is DNA
whats being sequenced. mRNA records also have T's. I think assigning alphabets
based on parsed sequence is overkill. Since it will make it more difficult to
translate (ambigous vs. unambigous - Translator exceptions). I would like the
parser to return IUPAC.ambigous_dna, but that is just my preference and since i
can fix it by a single record.alphabet assignment it is not critical at all.
(In reply to comment #1)
> So the GenBank file says in its header "ss-RNA" (single stranded RNA), and we
> obey this and set an RNA alphabet. However, as you point out, the actual
> sequence contains T not U, so is in fact given as DNA!
>
> Is this a bug in GenBank maybe...?
>
> Do you think we should switch the T's into U's to match the stated alphabet, or
> simply return a DNA sequence based on the content?
>
--
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.
From bugzilla-daemon at portal.open-bio.org Sat Nov 24 04:22:39 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Sat, 24 Nov 2007 04:22:39 -0500
Subject: [Biopython-dev] [Bug 2405] BioSQL gives UserWarning: ... not
recognised as database type: temporarily accepting key
In-Reply-To:
Message-ID: <200711240922.lAO9Mdrc018429@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2405
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-24 04:22 EST -------
Based on talking to a couple of the BioPerl guys, they don't do any mapping of
the db_xref at all. I see two options:
(a) Continue with the historical mapping in Biopython, and simply remove the
warning.
(b) Remove the mapping, just store the raw NCBI supplied db_xref terminology.
(c) Remove the mapping, except when reading data from the database in order to
retain backwards compatibility with data written using older versions of
Biopython [may not be required; until I fixed it recently the db_xref wasn't
even loaded for SeqFeatures]
I favour option (b) because its simpler and more compatible with the other Bio*
projects.
--
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.
From bugzilla-daemon at portal.open-bio.org Sun Nov 25 07:26:35 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Sun, 25 Nov 2007 07:26:35 -0500
Subject: [Biopython-dev] [Bug 2405] BioSQL gives UserWarning: ... not
recognised as database type: temporarily accepting key
In-Reply-To:
Message-ID: <200711251226.lAPCQZ7P004332@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2405
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-25 07:26 EST -------
Created an attachment (id=826)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=826&action=view)
Patch to BioSQL/__init__.py, Loader.py and BioSeq.py
Removes the mapping of db_xref keys.
Both unit tests pass, test_BioSQL.py and test_BioSQL_SeqIO.py
Any comments/objections from the mailing list to this being committed?
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 15:57:42 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 15:57:42 -0500
Subject: [Biopython-dev] [Bug 2410] New: DBSeq & DBSeqRecord should subclass
Seq & SeqRecord
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2410
Summary: DBSeq & DBSeqRecord should subclass Seq & SeqRecord
Product: Biopython
Version: 1.44
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
The DBSeq and DBSeqRecord classes are defined in BioSQL/BioSeq.py
They attempt to implement the core API defined for the corresponding objects in
Bio.Seq and Bio.SeqRecord, via database wrappers which load and caches data on
demand. The idea being that the DBSeqRecord and DBSeq can be used
interchangeably with the classic SeqRecord with Seq.
The problem is they are lacking several useful methods including __str__ and
__repr__ (see changes made to the Seq object on Bug 2351) and other Seq object
methods like count, complement and reverse_complement (see also enhancement Bug
2381).
I propose to make DBSeq and DBSeqRecord subclass Seq and SeqRecord
respectively. Trivial patch to follow - the two BioSQL unit tests seem to pass
just fine.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 16:05:55 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 16:05:55 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711262105.lAQL5t1c008299@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #14 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 16:05 EST -------
See also Bug 2410, there is a BioSQL DBSeq object which should be API
interchangeable with the Seq object. This would be another reason not to rush
into making Seq subclass the python string.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 16:05:58 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 16:05:58 -0500
Subject: [Biopython-dev] [Bug 2381] translate and transcibe methods for the
Seq object (in Bio.Seq)
In-Reply-To:
Message-ID: <200711262105.lAQL5wjp008318@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2381
------- Comment #10 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 16:05 EST -------
See also Bug 2410, there is a BioSQL DBSeq object which should be
interchangeable with the Seq object.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 16:15:08 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 16:15:08 -0500
Subject: [Biopython-dev] [Bug 2411] New: Slicing the DBSeq object (BioSQL's
Seq object)
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
Summary: Slicing the DBSeq object (BioSQL's Seq object)
Product: Biopython
Version: 1.44
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
The BioSQL version of the Seq object, DBSeq, raises a IndexError when
__getitem__ is given a slice with a stride.
See also Bug 2348 - Slicing the Seq object (returns a string when use a stride)
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 16:34:26 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 16:34:26 -0500
Subject: [Biopython-dev] [Bug 2411] Element access and slicing of DBSeq
object (BioSQL's Seq object)
In-Reply-To:
Message-ID: <200711262134.lAQLYQAY009394@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Slicing the DBSeq object |Element access and slicing
|(BioSQL's Seq object) |of DBSeq object (BioSQL's
| |Seq object)
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 16:34 EST -------
It gets worse - the existing DBSeq's __getslice__ doesn't even like negative
start/stop. Retitling bug to cover this too.
I'm making progress here :)
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 17:14:02 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 17:14:02 -0500
Subject: [Biopython-dev] [Bug 2411] Element access and slicing of DBSeq
object (BioSQL's Seq object)
In-Reply-To:
Message-ID: <200711262214.lAQME27B011121@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 17:14 EST -------
The element access only failed with an IndexError when attempted to get the
zero element by using an index of the negative length (i.e. a corner case).
That is fixed in BioSQL/BioSeq.py revision 1.15
Updated unit test in Test/test_BioSQL_SeqIO.py revision 1.6 checks basic
element access and slicing with the DBSeq object - but does not yet attempt
slicing with a stride (step).
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 17:39:37 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 17:39:37 -0500
Subject: [Biopython-dev] [Bug 2411] Element access and slicing of DBSeq
object (BioSQL's Seq object)
In-Reply-To:
Message-ID: <200711262239.lAQMdbUt012266@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 17:39 EST -------
Fixed in CVS, see:
BioSQL/BioSeq.py revision 1.16
Tests/test_BioSQL_SeqIO.py revision: 1.7
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 18:28:10 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 18:28:10 -0500
Subject: [Biopython-dev] [Bug 2411] Element access and slicing of DBSeq
object (BioSQL's Seq object)
In-Reply-To:
Message-ID: <200711262328.lAQNSATe014236@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
------- Comment #4 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 18:28 EST -------
Make that:
BioSQL/BioSeq.py revision 1.17
Tests/test_BioSQL_SeqIO.py revision: 1.8
I missed some "extreme" slice arguments which should have simply returned an
empty sequence but were raising an IndexError instead.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 18:37:29 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 18:37:29 -0500
Subject: [Biopython-dev] [Bug 2410] DBSeq & DBSeqRecord should subclass Seq
& SeqRecord
In-Reply-To:
Message-ID: <200711262337.lAQNbTFS014732@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2410
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 18:37 EST -------
Created an attachment (id=828)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=828&action=view)
Patch to BioSQL/BioSeq.py
This patch does the subclassing I suggested.
The full test suite still passes.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 27 06:16:25 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 27 Nov 2007 06:16:25 -0500
Subject: [Biopython-dev] [Bug 2405] db_xref and UserWarning: XXX not
recognised as database type: temporarily accepting key
In-Reply-To:
Message-ID: <200711271116.lARBGPMH012776@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2405
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Summary|BioSQL gives UserWarning: |db_xref and UserWarning: XXX
|... not recognised as |not recognised as database
|database type: temporarily |type: temporarily accepting
|accepting key |key
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-27 06:16 EST -------
Fixed in CVS by removing the db_xref mapping. This now follows BioPerl and
BioJava usage.
BioSQL/BioSeq.py revision 1.18
BioSQL/Loader.py revision 1.23
BioSQL/__init__.py revision 1.3
Both the BioSQL unit tests still pass.
[Also adding db_xref to the bug title to help anyone searching for this change
in future]
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 27 06:23:47 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 27 Nov 2007 06:23:47 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711271123.lARBNl83013085@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Comment #5 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-27 06:23 EST -------
I agree that in a few cases, it might be reasonable to automatically commit
changes (namely server.create_database, db.load records, and perhaps
server.remove_database) but not others (e.g. load_seqrecord).
Deciding everything on a case by case basis is a pain, and for the user it
means they can never be sure one way or the other without checking the
documentation or code.
I'm going to go with "won't fix", and in my defense refer to:
http://www.python.org/dev/peps/pep-0020/
The Zen Of Python, Point #2, "Explicit is better than implicit"
Now I/we need to work on the documentation ;)
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 28 07:24:10 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 28 Nov 2007 07:24:10 -0500
Subject: [Biopython-dev] [Bug 2412] New: NCBIXML. fails parsing with blast
2.2.15 in special cases (Karlin-Altschul)
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2412
Summary: NCBIXML. fails parsing with blast 2.2.15 in special
cases (Karlin-Altschul)
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Main Distribution
AssignedTo: biopython-dev at biopython.org
ReportedBy: bjoern.thorwirth at uni-due.de
this is the blas call i used: blastall -pblastp -dreference.fasta
-i/home/user/workspace/PLGDaemon/src/working_directories/blast_plugin/input2.fasta
-MPAM250 -m7 -e0.01 -gt -G-1 -E-1
XML output is empty.
Here is the Backtrace i got:
(Twisted Stuff)
File
"/home/user/Desktop/biopython/biopython-1.43/build/lib.linux-x86_64-2.4/Bio/Blast/NCBIXML.py",
line 625, in parse
assert len(blast_parser._records) == 0
exceptions.UnboundLocalError: local variable 'blast_parser' referenced before
assignment
(Twisted stuff)
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 28 07:25:48 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 28 Nov 2007 07:25:48 -0500
Subject: [Biopython-dev] [Bug 2412] NCBIXML. fails parsing with blast 2.2.15
in special cases (Karlin-Altschul)
In-Reply-To:
Message-ID: <200711281225.lASCPmY6013832@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2412
------- Comment #1 from bjoern.thorwirth at uni-due.de 2007-11-28 07:25 EST -------
Created an attachment (id=829)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=829&action=view)
Query Fasta
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 28 07:26:31 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 28 Nov 2007 07:26:31 -0500
Subject: [Biopython-dev] [Bug 2412] NCBIXML. fails parsing with blast 2.2.15
in special cases (Karlin-Altschul)
In-Reply-To:
Message-ID: <200711281226.lASCQVNp013895@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2412
------- Comment #2 from bjoern.thorwirth at uni-due.de 2007-11-28 07:26 EST -------
Created an attachment (id=830)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=830&action=view)
reference Fasta File
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 28 07:27:38 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 28 Nov 2007 07:27:38 -0500
Subject: [Biopython-dev] [Bug 2412] NCBIXML. fails parsing with blast 2.2.15
in special cases (Karlin-Altschul)
In-Reply-To:
Message-ID: <200711281227.lASCRcdl013938@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2412
------- Comment #3 from bjoern.thorwirth at uni-due.de 2007-11-28 07:27 EST -------
Created an attachment (id=831)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=831&action=view)
err out. XML File is empty
--
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.
From mdehoon at c2b2.columbia.edu Thu Nov 29 00:33:51 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Thu, 29 Nov 2007 00:33:51 -0500
Subject: [Biopython-dev] Bio.WWW.ExPASy
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B66C@mail2.exch.c2b2.columbia.edu>
Hi everybody,
The Bio.WWW reorganization has been completed for Bio.WWW.InterPro and
Bio.WWW.SCOP. Now I am looking at Bio.WWW.ExPASy.
Bio.WWW.ExPASy is used to access SwissProt, Prosite, and Prodoc records
through ExPASy. Because of the overlapping functionality in Bio.WWW.ExPASy I
now think it is better to keep this module together as Bio.ExPASy instead of
dividing it into Bio.SwissProt and Bio.Prosite.
Bio.WWW.ExPASy contains six functions:
get_prodoc_entry Interface to the get-prodoc-entry CGI script.
get_prosite_entry Interface to the get-prosite-entry CGI script.
get_prosite_raw Interface to the get-prosite-raw CGI script.
get_sprot_raw Interface to the get-sprot-raw CGI script.
sprot_search_ful Interface to the sprot-search-ful CGI script.
sprot_search_de Interface to the sprot-search-de CGI script.
plus an internally used function _open. (I added the get_prosite_raw function
as it was missing from the existing Bio.WWW.ExPASy).
These functions call the _open function with the appropriate URL.
Inside the _open function, we have the following code:
# Wrap the handle inside an UndoHandle.
uhandle = File.UndoHandle(handle)
# If the key doesn't exist, ExPASy returns nothing.
if not uhandle.peekline():
raise IOError, "no results"
Unfortunately, it is no longer true that ExPASy returns nothing for a
non-existing key. Nowadays, it returns an HTML web page with an error
message. The only exception is the get_prosite_raw function I just added;
here, ExPASy indeed returns nothing for a non-existing key.
So, the uhandle.peekline() will not fail even if the key is non-existing, and
the IOError will not be raised.
In this situation, I think it is better if the functions in Bio.WWW.ExPASy do
not attempt to raise an IOError, and to let the subsequent parsers handle
non-existing queries. The function get_prosite_raw could be an exception,
though I wouldn't be surprised if ExPASy one day decides to make its behavior
consistent with the other functions.
Any comments?
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From p.j.a.cock at googlemail.com Thu Nov 29 05:48:58 2007
From: p.j.a.cock at googlemail.com (Peter Cock)
Date: Thu, 29 Nov 2007 10:48:58 +0000
Subject: [Biopython-dev] Bio.WWW.ExPASy
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B66C@mail2.exch.c2b2.columbia.edu>
References: <6243BAA9F5E0D24DA41B27997D1FD14402B66C@mail2.exch.c2b2.columbia.edu>
Message-ID: <320fb6e00711290248k47363855x38a2fca8e978b323@mail.gmail.com>
> Bio.WWW.ExPASy contains six functions:
>
> get_prodoc_entry Interface to the get-prodoc-entry CGI script.
> get_prosite_entry Interface to the get-prosite-entry CGI script.
> get_prosite_raw Interface to the get-prosite-raw CGI script.
> get_sprot_raw Interface to the get-sprot-raw CGI script.
> sprot_search_ful Interface to the sprot-search-ful CGI script.
> sprot_search_de Interface to the sprot-search-de CGI script.
>
> plus an internally used function _open....
>
> Any comments?
Is it worth adding "download many" functions like the one in GenBank?
If the web API doesn't let us download a list of records by ID, then
we might need some sort of handle wrapper to download them one by one
- that might be too complicated.
Also, regarding handling HTML error pages, you could reuse the simple
code in Bio/WWW/NCBI.py which hunts for certain HTML errors. Or more
simply, try and spot when we get an HTML file instead of plain text?
There is a good case here for a shared "open a URL function" which can
spot HTML error pages.
Peter
From tiagoantao at gmail.com Thu Nov 29 13:25:48 2007
From: tiagoantao at gmail.com (Tiago Antao)
Date: Thu, 29 Nov 2007 18:25:48 +0000 (WET)
Subject: [Biopython-dev] coalescent tutorial text
Message-ID:
Hi,
I am currently writing the tutorial text for the coalescent code.
This text will talk about demography modeling, for which I would like to
include a few images of demographies. For a few examples you can see:
http://popgen.eu/soft/m4s2/list.png
Any opinions about including (more) images in the tutorial? Ideas on
reasonable limits? I was thinking in around half a dozen or so as a
maximum case scenario. Each image would probably occupy 1/10, 1/8 of a
page.
Tiago
From jkhilmer at gmail.com Thu Nov 29 16:50:57 2007
From: jkhilmer at gmail.com (Jonathan Hilmer)
Date: Thu, 29 Nov 2007 14:50:57 -0700
Subject: [Biopython-dev] Numeric dependencies, PDBParser.py
Message-ID: <81277ce10711291350p69341146o37cbdc84031cbdc0@mail.gmail.com>
Sorry if this has been covered before, but I'm new to the list and
haven't found anything searching through the archives.
I'm trying to use BioPython with 2.5 but I see that that PDBParser
requires Numeric. Is there any way to update this dependency besides
running tools to automatically alter code
(numpy.oldnumeric.alter_code1)?
I tried going through and changing 'Numeric import Float0' to 'numpy
import float' (in several \PDB\ files) until I found another Numeric
import of 'matrixmultiply'. Rather than continue on this path and
possibly break things (I'm a programming novice) I'm hoping someone
has an easier solution.
Thanks,
Jonathan
From mdehoon at c2b2.columbia.edu Thu Nov 29 23:00:24 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Thu, 29 Nov 2007 23:00:24 -0500
Subject: [Biopython-dev] Bio.WWW.ExPASy
References: <6243BAA9F5E0D24DA41B27997D1FD14402B66C@mail2.exch.c2b2.columbia.edu>
<320fb6e00711290248k47363855x38a2fca8e978b323@mail.gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B66D@mail2.exch.c2b2.columbia.edu>
> > Bio.WWW.ExPASy contains six functions:
> >
> > get_prodoc_entry Interface to the get-prodoc-entry CGI script.
> > get_prosite_entry Interface to the get-prosite-entry CGI script.
> > get_prosite_raw Interface to the get-prosite-raw CGI script.
> > get_sprot_raw Interface to the get-sprot-raw CGI script.
> > sprot_search_ful Interface to the sprot-search-ful CGI script.
> > sprot_search_de Interface to the sprot-search-de CGI script.
> >
> > plus an internally used function _open....
> >
> > Any comments?
>
> Is it worth adding "download many" functions like the one in GenBank?
> If the web API doesn't let us download a list of records by ID, then
> we might need some sort of handle wrapper to download them one by one
> - that might be too complicated.
For now, I'd like to focus just on the existing functions.
> Also, regarding handling HTML error pages, you could reuse the simple
> code in Bio/WWW/NCBI.py which hunts for certain HTML errors. Or more
> simply, try and spot when we get an HTML file instead of plain text?
> There is a good case here for a shared "open a URL function" which can
> spot HTML error pages.
Some of the functions in Bio.WWW.ExPASy return the records as a HTML page, so
just checking if the returned file is HTML or not won't suffice to find
non-existing keys. See the following table, showing the format of the record
/ the format of errors:
get_prodoc_entry HTML/HTML
get_prosite_entry HTML/HTML
get_prosite_raw Raw/Nothing
get_sprot_raw Raw/HTML
sprot_search_ful HTML/HTML
sprot_search_de HTML/HTML
Now, there are _extract_record functions in Bio.Prosite and
Bio.Prosite.Prodoc that take the output from get_prodoc_entry,
get_prosite_entry and fish out the record from the HTML. One possibility
would be to let the _extract_record function check for HTML error pages; this
function raises "ValueError: No data found in web page." if no data is found
in the HTML. But, if we call the appropriate _extract_record from
get_prodoc_entry, get_prosite_entry, then these two functions become very
close to what is already in Bio.Prosite.ExPASyDictionary and
Bio.Prosite.Prodoc.ExPASyDictionary. The ExPASyDictionaries use
get_prodoc_entry, get_prosite_entry to access ExPASy, and then extract the
record. So, if we call _extract_record inside get_prodoc_entry,
get_prosite_entry, then Bio.WWW.ExPASy.get_prodoc_entry(key) is virtually the
same as Bio.Prosite.Prodoc.ExPASyDictionary[key], and the same for Prosite.
So I think we have two options:
1) Bio.ExPASy contains the low-level functions to access ExPASy. No error
checking whatsoever; the calling function is responsible for making sure
that there is actually a record contained in the results.
Bio.Prosite.ExPASyDictionary, Bio.Prosite.Prodoc.ExPASyDictionary,
Bio.SwissProt.Sprot.ExPASyDictionary contain the high-level functions to
access ExPASy, which do the error checking and extract the record from the
HTML.
2) Make the only high-level functions available, to make sure the error
checking is always done.
My preference is 1).
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
Peter
From biopython at maubp.freeserve.co.uk Fri Nov 30 10:19:46 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Fri, 30 Nov 2007 15:19:46 +0000
Subject: [Biopython-dev] Numeric dependencies, PDBParser.py
In-Reply-To: <81277ce10711291350p69341146o37cbdc84031cbdc0@mail.gmail.com>
References: <81277ce10711291350p69341146o37cbdc84031cbdc0@mail.gmail.com>
Message-ID: <320fb6e00711300719mf2dd7cbt62061b9be80df99b@mail.gmail.com>
On Nov 29, 2007 9:50 PM, Jonathan Hilmer wrote:
> Sorry if this has been covered before, but I'm new to the list and
> haven't found anything searching through the archives.
>
> I'm trying to use BioPython with 2.5 but I see that that PDBParser
> requires Numeric.
Is there a problem installing Numeric? There is nothing to prevent you having
both Numeric and NumPy installed on the same machine.
> Is there any way to update this dependency besides
> running tools to automatically alter code
> (numpy.oldnumeric.alter_code1)?
Because Biopython also has some C code, moving the project as a whole
from Numeric to NumPy is non-trivial. You could try the patch on Bug 2251,
http://bugzilla.open-bio.org/show_bug.cgi?id=2251
Peter
From bugzilla-daemon at portal.open-bio.org Thu Nov 1 04:35:13 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 1 Nov 2007 00:35:13 -0400
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711010435.lA14ZD0G010559@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #8 from mdehoon at ims.u-tokyo.ac.jp 2007-11-01 00:35 EST -------
> > 3) The sequence should be mutable, so that we won't need a separate
> > MutableSeq class. This also implies that a Seq class cannot subclass from
> > string, since strings are not mutable.
>
> Why? Python strings are not mutable, and this isn't usually a problem.
> Personally, I have never needed a mutable sequence and have only ever
> used them in test cases.
For my research, I do need a mutable sequence.
> Having the basic Seq non-mutable means we can leverage existing
> string functionality and optimizations.
Thinking this over, I can see one more pressing reason to keep the basic Seq
immutable: If Seq is immutable, it can be used as the key in a dictionary, and
as a member of a set. With a mutable Seq, neither is possible. So I guess we
need to keep both a Seq and a MutableSeq class. We'll have to write a clearer
explanation though in the tutorial as to why two classes are needed.
> Also writing a new mutable sequence in C seems like a bit maintainance load in
> the long term (and may complicate the cross platform build process).
> Surely we can get good enough performance via the array of characters
> route currently used?
The array of characters approach allows us fast modification of sequences. On
the other hand, things like taking the complement is much slower than for
strings. I looked around a bit in the Python standard library and found that
there already is a MutableString class (located in the UserString module).
Since this class stores a immutable string internally, it is as fast as a
string. So how about letting the basic Seq class inherit from string, and the
MutableSeq class from MutableString?
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 1 08:49:44 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 1 Nov 2007 04:49:44 -0400
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711010849.lA18nieV030106@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #9 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-01 04:49 EST -------
> For my research, I do need a mutable sequence.
Diffent work, different needs.
> > Having the basic Seq non-mutable means we can leverage existing
> > string functionality and optimizations.
>
> Thinking this over, I can see one more pressing reason to keep the
> basic Seq immutable: If Seq is immutable, it can be used as the key
> in a dictionary, and as a member of a set. With a mutable Seq, neither
> is possible. So I guess we need to keep both a Seq and a MutableSeq class.
Those are both good points. The dictionary key thing is something I have used,
but hadn't thought about in my last comment.
> We'll have to write a clearer explanation though in the tutorial as to
> why two classes are needed.
Fair point.
> The array of characters approach allows us fast modification of sequences.
> On the other hand, things like taking the complement is much slower than for
> strings. I looked around a bit in the Python standard library and found that
> there already is a MutableString class (located in the UserString module).
> Since this class stores a immutable string internally, it is as fast as a
> string. So how about letting the basic Seq class inherit from string, and
> the MutableSeq class from MutableString?
That does sound sensible. One side effect of subclassing directly is the .data
property will vanish (the internal string/array of the Seq/MutableSeq object).
Some people will be using this (especially as it was actually used in some
older versions of the tutorial).
I propose we make the Seq/MutableSeq object act more string like (fix
str(my_seq) etc) for the next release and officially declare the .data
deprecated in the documentation. This should be backwards compatible - expect
where anyone used the str(my_seq) to get a truncated string deliberately. Then
shift to actual subclasses for a later release.
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 1 09:14:43 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 1 Nov 2007 05:14:43 -0400
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711010914.lA19EhEJ031362@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #6 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-01 05:14 EST -------
We may have two bugs here.
First of all your original problem, TypeError: not all arguments converted
during string formatting
If you could post the SQL query and the argument list (sql and arg) it might be
helpful. We should check that the data we are trying to insert into the
database matches the fields in the table.
Then we come to the new error, AttributeError: 'Cursor' object has no attribute
'insert_id'
I found a question on our own mailing list from Bela Tiwari, 4 November 2005
which shares this new problem and may shed some light on what is going wrong:
Begin quote
-------------------------------------------------------------------
Hello,
I am new to using biopython and biosql. I have been following the information
in the document Basic BioSQL with Biopython to try and get familiar with using
biopython to work with mysql databases and specifically I have tried to load a
Genbank file containing a small bacterial genome into a database.
I believe I have carried out all the instructions correctly (i.e. interpreted
to fit the system I am working on - Debian Sarge). The code and traceback call
that results is:
#############################
>>> >>> from BioSQL import BioSeqDatabase
>>> >>> from Bio import GenBank
>>> >>> server = BioSeqDatabase.open_database(driver="MySQLdb", user="root", host="localhost", db="bioseqdb")
>>> >>> db = server.new_database("testorama7")
>>> >>> parser = GenBank.FeatureParser()
>>> >>> iterator = GenBank.Iterator(open("CP000010.gbk"), parser)
>>> >>> db.load(iterator)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/site-packages/BioSQL/BioSeqDatabase.py", line 414,
in load
db_loader.load_seqrecord(cur_record)
File "/usr/lib/python2.3/site-packages/BioSQL/Loader.py", line 37, in
load_seqrecord
bioentry_id = self._load_bioentry_table(record)
File "/usr/lib/python2.3/site-packages/BioSQL/Loader.py", line 225, in
_load_bioentry_table
taxon_id = self._get_taxon_id(record)
File "/usr/lib/python2.3/site-packages/BioSQL/Loader.py", line 198, in
_get_taxon_id
taxon_id = self.adaptor.last_id("taxon")
File "/usr/lib/python2.3/site-packages/BioSQL/BioSeqDatabase.py", line 148,
in last_id
return self.dbutils.last_id(self.cursor, table)
File "/usr/lib/python2.3/site-packages/BioSQL/DBUtils.py", line 34, in
last_id
return cursor.insert_id()
AttributeError: 'Cursor' object has no attribute 'insert_id'
################################
I have seen information on the web suggesting that MySQLdb has undergone an API
change such that the insert_id() function has moved from the cursor to the
database object. Is it possible that such a change is at the core of my
problem? Or have I just done something wrong?
I am working on Debian Sarge, using biopython version 1.40b (though I have
checked the code for the latest release and nothing under BioSQL has changed).
Any advice anyone has about how to sort out this error would be greatly
appreciated.
cheers
Bela
-------------------------------------------------------------------
end quote.
Sadly I can't see any follow up emails, nor did she file a bug at the time, so
it looks like this issue was forgotten about.
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 1 09:24:21 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 1 Nov 2007 05:24:21 -0400
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711010924.lA19OL9K032066@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #7 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-01 05:24 EST -------
Created an attachment (id=801)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=801&action=view)
Untested patch to BioSQL/DBUtils.py
Based on a little google searching, this is my completely untested educated
guess for how to fix the cursor problem in BioSQL/DBUtils.py with the relevant
changed bit of code below:
class Mysql_dbutils(Generic_dbutils):
def last_id(self, cursor, table):
try :
#This worked on older versions of MySQL
return cursor.insert_id()
except AttributeError:
#See bug 2390.
#Google suggests this is the new way:
return cursor.lastrowid
If you feel brave and don't know how to work with patches, just back the
original file and then edit the class Mysql_dbutils to look like the above.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 5 16:22:22 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 5 Nov 2007 11:22:22 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711051622.lA5GMMxB008819@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #8 from Biosql at hotmail.com 2007-11-05 11:22 EST -------
Hi Peter,
Here's the SQL query :
INSERT INTO bioentry (
biodatabase_id,
name,
accession,
identifier,
division,
description,
version)
VALUES (%s,
%s,
%s,
%s,
%s,
%s,)"""
self.adaptor.execute(sql, (self.dbid, record.name,
accession,identifier,
division, description, version))
You can see there's a missing %s.
There's also a similar error in DBUtils module at line 23, where an argument is
also missing.
sql = r"select max(%s_id) from %s" % table
I've change the line with this one :
sql = r"select max(%s_id) from %s" % (table, table)
I also tried your suggested patch and I'm not receiving any error since, which
is great ! But, nothing's getting uploaded in the database... Crap...
Again, many thanks for the help 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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 5 19:49:40 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 5 Nov 2007 14:49:40 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711051949.lA5JnevZ004884@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #9 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-05 14:49 EST -------
Issue One
---------
Missing %s in BioSQL/Loader.py approx line 240. I think that as you suggest,
we should add a %s here.
This was removed in CVS version 1.18 (June 2007) by Michiel while working on
bug 1982. I think only one %s was meant to be removed (when the taxon_id was
removed), but it got done twice with the two related CVS commits.
Issue Two
---------
The cursor problem. I don't know if my suggestion in comment 7 is working or
not - it could be something else is going wrong to result in nothing in the
database.
Issue Three
-----------
Missing table argument in BioSQL/DBUtils.py line 23, I agree with you and have
fixed this in CVS revision 1.4.
In normal use the object is subclassed and the broken last_id method would
never have been called.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 5 21:49:09 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 5 Nov 2007 16:49:09 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711052149.lA5Ln9eC022511@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #10 from Biosql at hotmail.com 2007-11-05 16:49 EST -------
I'm using the DButils.py for now and it's working fine.
Now, I've checked the uploading problem with the BioSQL database and it seems
to me that It's getting stuck right at the beginning of the import with this
sql query :
INSERT INTO biodatabase (name, authority, description) VALUES ('Swiss', NULL,
NULL)
So, I've tried to repeat the same sql query in manual mode and I'm getting this
error :
1205, 'Lock wait timeout exceeded; try restarting transaction'
This error seems to be related to Innodb transaction.
Since, I'm very newb with InnoDB, cuz I've always been using MyISAM table I
really don't know what to do. Well, at least I'm gonna read on InnoDB table.
Thanks !
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 6 08:59:31 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 6 Nov 2007 03:59:31 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711060859.lA68xVZE014591@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #11 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-06 03:59 EST -------
> Now, I've checked the uploading problem with the BioSQL database and it
> seems to me that It's getting stuck right at the beginning of the import
> with this sql query :
>
> INSERT INTO biodatabase (name, authority, description)
> VALUES ('Swiss', NULL, NULL)
Do you know how to check the table schema, and see if authority and description
can be left empty/NULL?
I'm not sure what "authority" should be in this context, but it does strike me
as odd that the description is NULL - that could be a sequence file parsing
issue. Does this happen for all files you've tried - what about a GenBank
example?
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 7 04:55:50 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 6 Nov 2007 23:55:50 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711070455.lA74toCr023587@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #10 from mdehoon at ims.u-tokyo.ac.jp 2007-11-06 23:55 EST -------
> One side effect of subclassing directly is the .data property will vanish
> (the internal string/array of the Seq/MutableSeq object).
> Some people will be using this (especially as it was actually used in some
> older versions of the tutorial).
If we add
self.data = self
in the __init__ method of the Seq/MutableSeq classes, then the .data property
can still be used as before, without using significantly more memory.
> I propose we make the Seq/MutableSeq object act more string like (fix
> str(my_seq) etc) for the next release and officially declare the .data
> deprecated in the documentation. This should be backwards compatible - expect
> where anyone used the str(my_seq) to get a truncated string deliberately.
> Then shift to actual subclasses for a later release.
As we can keep the seq.data property even after subclassing, how about
subclassing right away for the next release?
--
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.
From tiagoantao at gmail.com Wed Nov 7 11:09:44 2007
From: tiagoantao at gmail.com (Tiago Antao)
Date: Wed, 07 Nov 2007 11:09:44 +0000
Subject: [Biopython-dev] resuming CVS updates
Message-ID: <47319CF8.8020507@gmail.com>
Hi,
Is it OK to resume with CVS updates of non-production code? (No rush or
urgency, just to know...)
Tiago
--
tiagoantao at gmail.com
http://tiago.org/ps
From mdehoon at c2b2.columbia.edu Thu Nov 8 01:06:03 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Wed, 7 Nov 2007 20:06:03 -0500
Subject: [Biopython-dev] resuming CVS updates
References: <47319CF8.8020507@gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B656@mail2.exch.c2b2.columbia.edu>
Since no disasters showed up with the 1.44 release, I think it is OK to
resume CVS updates.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
-----Original Message-----
From: biopython-dev-bounces at lists.open-bio.org on behalf of Tiago Antao
Sent: Wed 11/7/2007 6:09 AM
To: biopython-dev at biopython.org
Subject: [Biopython-dev] resuming CVS updates
Hi,
Is it OK to resume with CVS updates of non-production code? (No rush or
urgency, just to know...)
Tiago
--
tiagoantao at gmail.com
http://tiago.org/ps
_______________________________________________
Biopython-dev mailing list
Biopython-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biopython-dev
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 12:34:07 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 07:34:07 -0500
Subject: [Biopython-dev] [Bug 2393] New: Bio.GenBank.NCBIDictionary fails
with release 1.44
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
Summary: Bio.GenBank.NCBIDictionary fails with release 1.44
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Main Distribution
AssignedTo: biopython-dev at biopython.org
ReportedBy: mdehoon at ims.u-tokyo.ac.jp
In Biopython release 1.44, some magic code in Bio/__init__.py was removed. This
causes Bio.GenBank.NCBIDictionary to fail, since Bio.db is no longer known. See
this message from Eric Gibert on the mailing list:
http://lists.open-bio.org/pipermail/biopython/2007-November/003876.html
This code example shows the error:
>>> from Bio.GenBank import NCBIDictionary
>>> d = NCBIDictionary("nucleotide","genbank")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/site-packages/Bio/GenBank/__init__.py", line 1283,
in
__init__
from Bio import db
ImportError: cannot import name db
>>>
The attached patch is a first attempt to resurrect the NCBIDictionary
functionality, using NCBI's EUtils directly instead of going though Bio.db. One
important difference is that __getitem__ now returns a handle instead of the
record contents. NCBIDictionary can then be used as follows:
>>> from Bio.GenBank import NCBIDictionary
>>> d = NCBIDictionary("nucleotide","genbank")
>>> handle = d['57282195']
>>> from Bio import SeqIO
>>> record = SeqIO.parse(handle, "genbank").next()
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 12:35:09 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 07:35:09 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711081235.lA8CZ9oo020618@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
mdehoon at ims.u-tokyo.ac.jp changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|biopython-dev at biopython.org |mdehoon at ims.u-tokyo.ac.jp
Status|NEW |ASSIGNED
------- Comment #1 from mdehoon at ims.u-tokyo.ac.jp 2007-11-08 07:35 EST -------
Created an attachment (id=803)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=803&action=view)
Patch for Bio/GenBank/__init__.py
--
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.
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 16:26:00 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:26:00 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711081626.lA8GQ0kA032150@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #801 is|0 |1
obsolete| |
------- Comment #12 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-08 11:25 EST -------
(From update of attachment 801)
Checked into CVS, see BioSQL/DBUtils.py revision 1.5, after Eric Gibert
suggested the same fix on the mailing list.
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 16:36:26 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:36:26 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711081636.lA8GaQTG000341@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #13 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-08 11:36 EST -------
Issue One
---------
Missing %s in BioSQL/Loader.py approx line 240. Fixed in CVS, BioSQL/Loader.py
revision 1.19
Issue Two
---------
The cursor problem. I've checked in the suggested fix from my comment 7, Eric
Gibert suggested the same thing on the mailing list.
Eric's email suggests we also have to do something about finishing the SQL
transaction - i.e. actually doing a commit to save the inserted records in the
databse.
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 16:47:10 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:47:10 -0500
Subject: [Biopython-dev] [Bug 2394] New: INSERT INTO
seqfeature_qualifier_value ...
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2394
Summary: INSERT INTO seqfeature_qualifier_value ...
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
Reported on the mailing list by Eric Gibert, as pointed out by Hilmar Lapp any
SQL statement which relies on the field order not changing is fragile. My
patch to follow...
Eric wrote:
In my BioSQL database, the table 'seqfeature_qualifier_value' as the following
schema:
seqfeature_id int(11)
term_id int(11)
value varchar(255)
rank int(11)
note that first we have 'value' then we have 'rank'.
But the 'INSERT INTO seqfeature_qualifier_value' statement found in
BioSQL/Loader.py line 453 is:
qualifier_value =
qualifiers[qualifier_key][qual_value_rank]
sql = r"INSERT INTO seqfeature_qualifier_value VALUES" \
r" (%s, %s, %s, %s)"
self.adaptor.execute(sql, (seqfeature_id,
qualifier_key_id,
qual_value_rank + 1,
qualifier_value))
thus I need to invert the last two elements of the list. As I said, I do not
know if my BioSQL schema is correct or not.
If my schema is correct then my correction is obvious:
self.adaptor.execute(sql, (seqfeature_id,
qualifier_key_id,
qualifier_value, # EG
invert the two last params
qual_value_rank + 1
))
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 16:49:05 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:49:05 -0500
Subject: [Biopython-dev] [Bug 2394] INSERT INTO seqfeature_qualifier_value
...
In-Reply-To:
Message-ID: <200711081649.lA8Gn57i001263@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2394
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-08 11:49 EST -------
Created an attachment (id=804)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=804&action=view)
Patch to BioSQL/Loader.py
List the fields explicitly in the SQL statement.
See also:
http://www.bioperl.org/SRC/biosql-schema/sql/biosqldb-mysql.sql
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 8 16:55:15 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 8 Nov 2007 11:55:15 -0500
Subject: [Biopython-dev] [Bug 2394] INSERT INTO seqfeature_qualifier_value
...
In-Reply-To:
Message-ID: <200711081655.lA8GtFRp001632@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2394
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-08 11:55 EST -------
If Eric is reading this, could you tell us where you got your BioSQL database
schema from? Your column order differs from what I would expect from these:
http://www.bioperl.org/SRC/biosql-schema/sql/biosqldb-mysql.sql
http://www.bioperl.org/SRC/biosql-schema/sql/biosqldb-pg.sql
With the patch, Biopython should cope with the fields in this table being in
any order.
--
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.
From bugzilla-daemon at portal.open-bio.org Fri Nov 9 06:04:50 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 9 Nov 2007 01:04:50 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711090604.lA964oVN001747@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
mdehoon at ims.u-tokyo.ac.jp changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |biopython-dev at biopython.org
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Fri Nov 9 10:55:24 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 9 Nov 2007 05:55:24 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711091055.lA9AtO2Y014627@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #4 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-09 05:55 EST -------
Creating a new handle based interface, and using this internally within
Bio.GenBank.NCBIDictionary to provide the old API sounds very sensible. As you
say, we /could/ then one day deprecate Bio.GenBank.NCBIDictionary.
Your point about avoiding UEtils is understandable. How about using the far
simpler Bio.WWW.NCBI wrapper? This has basic error checking and means hard
coding the URL in one place only. In fact, this could be a good place to put a
new Dictionary, e.g. Bio.WWW.NCBI.EntrezDictionary rather than
Bio.Entrez.Dictionary
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Fri Nov 9 12:04:09 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 9 Nov 2007 07:04:09 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711091204.lA9C49OT017953@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #5 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-09 07:04 EST -------
Created an attachment (id=805)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=805&action=view)
Possible new unit test
This is a possible unit test which uses
Bio.GenBank.NCBIDictionary and a few other online sources of data, and checks
we can parse them with Bio.SeqIO
I have been testing this with my one line short term import hack (checked in by
the way - with the expectation your code will replace it). Note that this does
give a DeprecationWarning from Bio/config/DBRegistry.py
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 06:35:27 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 01:35:27 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711120635.lAC6ZRFD023790@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #6 from mdehoon at ims.u-tokyo.ac.jp 2007-11-12 01:35 EST -------
> Your point about avoiding UEtils is understandable. How about using the far
> simpler Bio.WWW.NCBI wrapper? This has basic error checking and means hard
> coding the URL in one place only. In fact, this could be a good place to put a
> new Dictionary, e.g. Bio.WWW.NCBI.EntrezDictionary rather than
> Bio.Entrez.Dictionary
I'd be happy to use the code from Bio.WWW.NCBI, but I don't think that Bio.WWW
is a good location for an EntrezDictionary class. As a case in point, I didn't
know that Bio.WWW contains code to access NCBI Entrez, and I couldn't guess it
from its name. With a module like Bio.GenBank, it is clear from its name what
it is about. Furthermore, the different submodules Bio.WWW.ExPASy,
Bio.WWW.InterPro, Bio.WWW.NCBI, and Bio.WWW.SCOP don't seem to have much in
common. I think that the existing modules Bio.SwissProt, Bio.Prosite,
Bio.InterPro, Bio.SCOP, containing the respective parsers, are more logical
places to keep the database access code.
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 10:25:32 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 05:25:32 -0500
Subject: [Biopython-dev] [Bug 2395] New: Need a commit in db.load (BioSQL
with MySQL)
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
Summary: Need a commit in db.load (BioSQL with MySQL)
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
As noted in bug 1921 and more recently on the mailing and bug 2390, it seem
Biopython should be doing a database commit with MySQL.
e.g. Leighton Pritchard wrote on bug 1921 comment 3
>>> from BioSQL import BioSeqDatabase
>>> server = BioSeqDatabase.open_database(driver="MySQLdb", user="root", passwd=
"", host="localhost", db="bioseqdb")
>>> db = server.new_database("cold")
>>> from Bio import GenBank
>>> parser = GenBank.FeatureParser()
>>> iterator = GenBank.Iterator(file("cor6_6.gb"), parser)
>>> db.load(iterator)
6
>>>
However, there is now an additional new problem when using MySQL5, as the
necessary commit is not automatically executed, and a direct call of
>>> server.adaptor.commit()
seems to be necessary after the above in order to commit the changes to the
database.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 10:26:33 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 05:26:33 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711121026.lACAQXlS002017@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #14 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-12 05:26 EST -------
Issue Two
---------
The cursor problem. As I said, I've checked in the suggested fix from my
comment 7, since Eric Gibert suggested the same thing on the mailing list.
More or less the same issue was reported as bug 1979 with a slightly
different solution: http://bugzilla.open-bio.org/show_bug.cgi?id=1979
Regarding the cursor problem, reading up on bug 1921, since perhaps MySQL 5,
Biopython has needed to manually do a commit. I've filed bug 2395
http://bugzilla.open-bio.org/show_bug.cgi?id=1921
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 10:30:56 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 05:30:56 -0500
Subject: [Biopython-dev] [Bug 1921] BioSeqDatabase.load() method fails
In-Reply-To:
Message-ID: <200711121030.lACAUuqA002275@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=1921
------- Comment #8 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-12 05:30 EST -------
I've filed bug 2395 on the commit issue as that seems to still be outstanding.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 12 12:32:05 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 12 Nov 2007 07:32:05 -0500
Subject: [Biopython-dev] [Bug 1921] BioSeqDatabase.load() method fails
In-Reply-To:
Message-ID: <200711121232.lACCW5ST008594@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=1921
mcolosimo at mitre.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mcolosimo at mitre.org
------- Comment #9 from mcolosimo at mitre.org 2007-11-12 07:32 EST -------
(In reply to comment #6)
> Hi Michiel,
>
> I've had no further issues since I put in the patch locally, so it works for
> me, at least. No doubt someone will point out any further problems that I've
> missed in my usage ;)
>
> L.
>
Does this fix what I reported and submitted?
Marc
--
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.
From mdehoon at c2b2.columbia.edu Tue Nov 13 06:52:54 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 01:52:54 -0500
Subject: [Biopython-dev] Bio.WWW; database access
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
Hi everybody,
Recently Eric Gibert wrote to us about Bio.GenBank.NCBIDictionary failing
with Biopython 1.44. We already have a fix for this error in CVS, but when I
was looking into this bug in more detail I started wondering about the way
database access is organized in Biopython.
Currently, code to access NCBI Entrez exists in three places:
1) Bio.WWW.NCBI
2) Bio.GenBank (in NCBIDictionary)
3) Bio.EUtils
Bio.WWW contains three more submodules for database access:
1) Bio.WWW.ExPASy, to access Swissprot, Prodoc, Prosite
2) Bio.WWW.InterPro, to access InterPro
3) Bio.WWW.SCOP, to access the SCOP database
The parsers for these modules are in a different location:
1a) Bio.SwissProt
1b) Bio.Prosite
1c) Bio.Prosite.Prodoc
2) Bio.InterPro
3) Bio.SCOP
To me, it seems odd that the code for database access and the code to parse
files downloaded from the database are in different locations. For example,
when I was working on Bio.GenBank, it did not occur to me that such code
might already exist in Bio.WWW.
Now, Bio.WWW.SCOP is a very small module (64 lines total), and
Bio.WWW.InterPro seems to be out of date. With Bio.WWW.NCBI containing
functionality that also exists elsewhere in Biopython, having a separate
Bio.WWW module doesn't seem to be optimal in terms of code organization. I'd
prefer to have the code for database access together with the respective code
for parsing.
Any opinions?
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 09:24:31 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 04:24:31 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711130924.lAD9OV2K014516@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #7 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 04:24 EST -------
Michiel has moved this discussion to the developers' mailing list.
> I'd be happy to use the code from Bio.WWW.NCBI, but I don't think that
> Bio.WWW is a good location for an EntrezDictionary class. As a case in point,
> I didn't know that Bio.WWW contains code to access NCBI Entrez, and I
> couldn't guess it from its name.
I correctly guessed from the name Bio.WWW.NCBI that it was an API for the
NCBI's online tools (but I tend to refer to the NCBI rather than Entrez in
conversation).
> With a module like Bio.GenBank, it is clear from its name what it is about.
Yes, it does mean both the file format and the online database.
> Furthermore, the different submodules Bio.WWW.ExPASy, Bio.WWW.InterPro,
> Bio.WWW.NCBI, and Bio.WWW.SCOP don't seem to have much in common.
Apart from all being interfaces to online/web databases? Well no, but if this
was followed more strictly it would make the top level module list much
shorter.
> I think that the existing modules Bio.SwissProt, Bio.Prosite, Bio.InterPro,
> Bio.SCOP, containing the respective parsers, are more logical places to keep
> the database access code.
Maybe. I agree we should rationalise things, and getting rid of Bio.WWW might
be the most straight forward simplification - see mailing list.
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From tiagoantao at gmail.com Tue Nov 13 09:30:50 2007
From: tiagoantao at gmail.com (Tiago Antao)
Date: Tue, 13 Nov 2007 09:30:50 +0000
Subject: [Biopython-dev] uploading coalescent code
Message-ID: <47396ECA.2060902@gmail.com>
Hi,
I am going to start uploading coalescent code (unless somebody disagrees).
A few points about this code:
1. It was already published and has users (google for modeler4simcoal2),
so it should be fairly stable.
2. It has some purpose and hopefully some audience (the code that is in
Bio.PopGen currently is for less important things - is was used by
myself mainly to get acquainted with the developer process).
3. IMPORTANT: There are some text template files. I suppose that there
is no standard way to have datafiles around. I was thinking (actually
somebody suggested on this list) in putting it alongside the code.
Question: Is there any standard way to know where biopython is installed
(so that I can read those datafiles)? We are talking of very small files.
Thanks,
Tiago
--
tiagoantao at gmail.com
http://tiago.org/ps
From biopython-dev at maubp.freeserve.co.uk Tue Nov 13 09:10:41 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Tue, 13 Nov 2007 09:10:41 +0000
Subject: [Biopython-dev] Bio.WWW; database access
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
Message-ID: <47396A11.8020705@maubp.freeserve.co.uk>
Michiel De Hoon wrote:
> Hi everybody,
>
> Recently Eric Gibert wrote to us about Bio.GenBank.NCBIDictionary failing
> with Biopython 1.44. We already have a fix for this error in CVS, but when I
> was looking into this bug in more detail I started wondering about the way
> database access is organized in Biopython.
See also bug 2393 for the background to this discussion.
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
> Currently, code to access NCBI Entrez exists in three places:
> 1) Bio.WWW.NCBI
> 2) Bio.GenBank (in NCBIDictionary)
> 3) Bio.EUtils
>
> Bio.WWW contains three more submodules for database access:
> 1) Bio.WWW.ExPASy, to access Swissprot, Prodoc, Prosite
> 2) Bio.WWW.InterPro, to access InterPro
> 3) Bio.WWW.SCOP, to access the SCOP database
>
> The parsers for these modules are in a different location:
> 1a) Bio.SwissProt
> 1b) Bio.Prosite
> 1c) Bio.Prosite.Prodoc
> 2) Bio.InterPro
> 3) Bio.SCOP
>
> To me, it seems odd that the code for database access and the code to parse
> files downloaded from the database are in different locations. For example,
> when I was working on Bio.GenBank, it did not occur to me that such code
> might already exist in Bio.WWW.
My initially reaction was different - having noticed there was a WWW
module (it caught my eye being the last directory) I initially looked
there for online resources.
> Now, Bio.WWW.SCOP is a very small module (64 lines total), and
> Bio.WWW.InterPro seems to be out of date. With Bio.WWW.NCBI containing
> functionality that also exists elsewhere in Biopython, having a separate
> Bio.WWW module doesn't seem to be optimal in terms of code organization. I'd
> prefer to have the code for database access together with the respective code
> for parsing.
>
> Any opinions?
I do agree that having things in two places is not optimal for new
users, and on balance having code to access the online resource
associated with a file format in the same place as the parsers seems
reasonable.
However, what about the fact that some online resources (e.g. GenBank)
will return several sorts of data (e.g. journal references and
sequences) and/or in a range of file formats (e.g. GenBank, Fasta, XML,
...). In this situation, having the online interface separate from the
format parsers makes some sense. I am perhaps being a devil's advocate
here.
Peter
From mdehoon at c2b2.columbia.edu Tue Nov 13 09:52:44 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 04:52:44 -0500
Subject: [Biopython-dev] uploading coalescent code
References: <47396ECA.2060902@gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65C@mail2.exch.c2b2.columbia.edu>
Hi Tiago,
> 3. IMPORTANT: There are some text template files. I suppose that there
> is no standard way to have datafiles around. I was thinking (actually
> somebody suggested on this list) in putting it alongside the code.
> Question: Is there any standard way to know where biopython is installed
> (so that I can read those datafiles)? We are talking of very small files.
Have you looked at the manual for distutils? Section 2.6 and 2.7 discuss
having data files distributed with a Python extension. See
http://docs.python.org/dist/dist.html
Given that such an option exists, somebody must already be using it. So I
think your best option is to google around a bit to find some examples.
--Michiel
From biopython-dev at maubp.freeserve.co.uk Tue Nov 13 10:07:22 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Tue, 13 Nov 2007 10:07:22 +0000
Subject: [Biopython-dev] Biopython SVN Transition
In-Reply-To: <128a885f0710302255y4c34ac8axa48f48b253d5854a@mail.gmail.com>
References: <128a885f0710300717p7d91a4adjfaddc9c496974e67@mail.gmail.com> <47278655.8090300@maubp.freeserve.co.uk>
<128a885f0710302255y4c34ac8axa48f48b253d5854a@mail.gmail.com>
Message-ID: <4739775A.1020208@maubp.freeserve.co.uk>
Chris Lasher wrote:
>> In terms of timing, how long do you/the OBF guys expect the transfer to
>> take? And would they prefer to do this over a weekend or mid week?
>
> Not sure, let me ask Jason Stajich.
> ...
> I think we could expect less than a full day downtime.
Any preference on mid week versus weekend? I'm still happy with any time
in the next fortnight.
>> P.S. Would you or any of the people doing the transition be able to sort
>> out bug 2363?
>> http://bugzilla.open-bio.org/show_bug.cgi?id=2363
>
> That's a very good question. I wonder if cvs2svn is capable of picking
> up those errors in commits and choose the proper format. I had trouble
> getting a hold of an expert who could tell me how to identify files
> committed as binary files, and how to change that to text (or vice
> versa). I should send an email to the Subversion mailing list,
> perhaps, or the CVS list if it's still active. I'll also check to see
> if Jason knows.
If you can solve this, it would make life easier for building from
source on Windows :)
Thanks
Peter
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 10:23:59 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 05:23:59 -0500
Subject: [Biopython-dev] [Bug 2380] Bio.Nexus is adding "?" and "-" to
Bio.Data.IUPACData.ambiguous_dna_values
In-Reply-To:
Message-ID: <200711131023.lADANxcg017625@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2380
tiagoantao at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tiagoantao at gmail.com
------- Comment #1 from tiagoantao at gmail.com 2007-11-13 05:23 EST -------
As I found this, I already have some knowledge of the problem.
I am volunteering to try to solve it.
If somebody would prefer me not to do this, please say. If not, in a couple of
days I will assign it to myself and start working.
--
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.
From tiagoantao at gmail.com Tue Nov 13 10:25:32 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Tue, 13 Nov 2007 10:25:32 +0000
Subject: [Biopython-dev] uploading coalescent code
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B65C@mail2.exch.c2b2.columbia.edu>
References: <47396ECA.2060902@gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B65C@mail2.exch.c2b2.columbia.edu>
Message-ID: <6d941f120711130225u7d6041e5n8dc6a70f1df2a945@mail.gmail.com>
Hi,
I should have done my home work better before asking this in the list, sorry.
According to the manual, there are 2 options:
# 2.6 Installing Package Data
# 2.7 Installing Additional Files
Being strictly correct, we are talking about "additional files", but,
to make things simpler (and avoiding clutering biopython with probably
more top-level directories) I think "package data" is enough.
If nobody sees a problem I will add a data directory inside
Bio/PopGen/SimCoal and upload it to CVS.
But, there is a more serious change: setup.py. For this I suggest:
1. Adding you to the SimCoal feature bug 2375, can I do that?
2. I would put my suggested diff there and you could
evaluate/change/accept/reject it
On Nov 13, 2007 9:52 AM, Michiel De Hoon wrote:
> Hi Tiago,
>
> > 3. IMPORTANT: There are some text template files. I suppose that there
> > is no standard way to have datafiles around. I was thinking (actually
> > somebody suggested on this list) in putting it alongside the code.
> > Question: Is there any standard way to know where biopython is installed
> > (so that I can read those datafiles)? We are talking of very small files.
>
> Have you looked at the manual for distutils? Section 2.6 and 2.7 discuss
> having data files distributed with a Python extension. See
>
> http://docs.python.org/dist/dist.html
>
> Given that such an option exists, somebody must already be using it. So I
> think your best option is to google around a bit to find some examples.
>
> --Michiel
>
>
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 10:36:42 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 05:36:42 -0500
Subject: [Biopython-dev] [Bug 2380] Bio.Nexus is adding "?" and "-" to
Bio.Data.IUPACData.ambiguous_dna_values
In-Reply-To:
Message-ID: <200711131036.lADAagXG018746@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2380
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 05:36 EST -------
I think Nexus should just create a copy of ambiguous_dna_values and any related
lists/dicts, and add things to the copy. I'm happy to review a patch if you
want to tackle this Tiago.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 11:18:41 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 06:18:41 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711131118.lADBIfPV021081@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Need a commit in db.load |Need a commit in BioSQL with
|(BioSQL with MySQL) |MySQL
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 06:18 EST -------
As might be expected with hindsight, this is more general than just db.load(),
and seems to apply to any operation.
One suggestion on the mailing list from Eric Gibert,
[quote]
Finally, the script executes without error and .... nothing happens! It looks
like there is no 'commit' nowhere and so the new records are not inserted in
the database.
Although the psychopg database enjoys a:
def autocommit(self, conn, y = True):
conn.autocommit(y)
_dbutils["psycopg"] = Psycopg_dbutils
MySQL does not have such an overload for 'autocommit' in DBUtils.py. Could this
fix the problem ?
In the file MySQLdb/connections.py, on line 213, we have:
# PEP-249 requires autocommit to be initially off
self.autocommit(False)
Therefore the source for the Mysql_dbutils class is now:
class Mysql_dbutils(Generic_dbutils):
def last_id(self, cursor, table):
return cursor.lastrowid #EG original command: cursor.insert_id()
def autocommit(self, conn, y = True): # EG addition as by default it is set
to False
conn.autocommit(y)
_dbutils["MySQLdb"] = Mysql_dbutils
Unfortunately, this is *NOT* fixing the lack of 'commit'. I need your help...
[/quote]
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 11:26:45 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 06:26:45 -0500
Subject: [Biopython-dev] [Bug 2394] INSERT INTO seqfeature_qualifier_value
...
In-Reply-To:
Message-ID: <200711131126.lADBQjMX021544@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2394
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 06:26 EST -------
Confirmed this change works fine, fix checked into CVS
biopython/BioSQL/Loader.py revision 1.21
Marking as fixed.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 11:30:41 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 06:30:41 -0500
Subject: [Biopython-dev] [Bug 2380] Bio.Nexus is adding "?" and "-" to
Bio.Data.IUPACData.ambiguous_dna_values
In-Reply-To:
Message-ID: <200711131130.lADBUf0G021925@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2380
tiagoantao at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|biopython-dev at biopython.org |tiagoantao at gmail.com
--
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.
You are the assignee for the bug, or are watching the assignee.
From mdehoon at c2b2.columbia.edu Tue Nov 13 11:32:08 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 06:32:08 -0500
Subject: [Biopython-dev] uploading coalescent code
References: <47396ECA.2060902@gmail.com><6243BAA9F5E0D24DA41B27997D1FD14402B65C@mail2.exch.c2b2.columbia.edu>
<6d941f120711130225u7d6041e5n8dc6a70f1df2a945@mail.gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65D@mail2.exch.c2b2.columbia.edu>
> But, there is a more serious change: setup.py. For this I suggest:
> 1. Adding you to the SimCoal feature bug 2375, can I do that?
> 2. I would put my suggested diff there and you could
> evaluate/change/accept/reject it
Sure, that is fine.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
On Nov 13, 2007 9:52 AM, Michiel De Hoon wrote:
> Hi Tiago,
>
> > 3. IMPORTANT: There are some text template files. I suppose that there
> > is no standard way to have datafiles around. I was thinking (actually
> > somebody suggested on this list) in putting it alongside the code.
> > Question: Is there any standard way to know where biopython is installed
> > (so that I can read those datafiles)? We are talking of very small files.
>
> Have you looked at the manual for distutils? Section 2.6 and 2.7 discuss
> having data files distributed with a Python extension. See
>
> http://docs.python.org/dist/dist.html
>
> Given that such an option exists, somebody must already be using it. So I
> think your best option is to google around a bit to find some examples.
>
> --Michiel
>
>
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 11:33:15 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 06:33:15 -0500
Subject: [Biopython-dev] [Bug 2386] Bio.Seq.Seq and MutableSeq count()
method only works for single residues
In-Reply-To:
Message-ID: <200711131133.lADBXF3l022073@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2386
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #6 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 06:33 EST -------
Marking as fixed, count method patch checked into CVS, see biopython/Bio/Seq.py
revision 1.20
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 12:52:46 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 07:52:46 -0500
Subject: [Biopython-dev] [Bug 2396] New: BioSQL loader does not store
sequence level annotations dict
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
Summary: BioSQL loader does not store sequence level annotations
dict
Product: Biopython
Version: 1.44
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
Reported on the mailing list by Eric Gibert.
Basically while features have their annotations recorded, most of the top level
SeqRecord's annotations dictionary is ignored.
I'm about to attach a possible patch; this still needs work for the case where
the annotations dictionary contains non-string values (e.g. lists of strings)
and I may want to tweak the reconstruction of the record on retreival from the
database.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 12:54:29 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 07:54:29 -0500
Subject: [Biopython-dev] [Bug 2396] BioSQL loader does not store sequence
level annotations dict
In-Reply-To:
Message-ID: <200711131254.lADCsTeE026220@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 07:54 EST -------
Created an attachment (id=806)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=806&action=view)
Patch to BioSQL/Loader.py
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 13:07:28 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 08:07:28 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711131307.lADD7SO4026877@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
------- Comment #15 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 08:07 EST -------
I haven't downloaded the 1GB uniprot_sprot.dat file, however using the example
files from biopython/Tests/SwissProt seems to work for me now using CVS:
from BioSQL import BioSeqDatabase
from Bio import SeqIO
import os
server = BioSeqDatabase.open_database(driver='MySQLdb', user='root', passwd='',
host='localhost', db='bioseqdb')
db = server.new_database('bug2390')
for filename in os.listdir(".") :
if filename[:2]=="sp" :uniprot_sprot.dat
print "Loading %s" % filename
db.load(SeqIO.parse(open(filename), "swiss"))
print "Committing..."
server.adaptor.commit()
The commit issue is covered by bug 2395, so I would like to mark this as fixed.
Jon - could you update your copy of Biopython and re-test? Thanks
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 16:12:27 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 11:12:27 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711131612.lADGCR0n004960@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #736 is|0 |1
obsolete| |
------- Comment #11 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 11:12 EST -------
(From update of attachment 736)
Something similar checked in as biopython/Bio/Seq.py revision 1.21
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 16:12:49 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 11:12:49 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711131612.lADGCnfi005023@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #751 is|0 |1
obsolete| |
------- Comment #12 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 11:12 EST -------
(From update of attachment 751)
Something similar checked in as biopython/Bio/Seq.py revision 1.21
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 16:15:26 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 11:15:26 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711131615.lADGFQTj005269@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #13 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 11:15 EST -------
I've updated the __str__ methods in CVS to act like strings; I'll take care of
the unit tests this breaks next.
> As we can keep the seq.data property even after subclassing, how
> about subclassing right away for the next release?
Maybe, but doing that properly that does mean a lot more work - we have to
implement alphabet aware versions all the string methods.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 18:19:46 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 13:19:46 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711131819.lADIJkpI012007@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #797 is|0 |1
obsolete| |
------- Comment #16 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 13:19 EST -------
(From update of attachment 797)
This attachment has been removed
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 18:19:53 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 13:19:53 -0500
Subject: [Biopython-dev] [Bug 2397] New: test_PopGen_FDist does not fail
gracefully on Windows
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2397
Summary: test_PopGen_FDist does not fail gracefully on Windows
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: Windows
Status: NEW
Severity: minor
Priority: P2
Component: PopGen
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
On Linux, test_PopGen_FDist.py can detect when the fdist program is missing,
and raises the missing external dependancy exception (trapped by the test
harness).
On Windows, this does not work properly - the OS error is not caught.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 18:20:31 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 13:20:31 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711131820.lADIKVOn012120@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #798 is|0 |1
obsolete| |
------- Comment #17 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-13 13:20 EST -------
(From update of attachment 798)
This attachment has been removed
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 13 18:23:25 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 13 Nov 2007 13:23:25 -0500
Subject: [Biopython-dev] [Bug 2397] test_PopGen_FDist does not fail
gracefully on Windows
In-Reply-To:
Message-ID: <200711131823.lADINPXH012319@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2397
tiagoantao at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|biopython-dev at biopython.org |tiagoantao at gmail.com
------- Comment #1 from tiagoantao at gmail.com 2007-11-13 13:23 EST -------
I will install biopython on windows and correct this.
--
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.
You are the assignee for the bug, or are watching the assignee.
From mdehoon at c2b2.columbia.edu Wed Nov 14 02:16:06 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 21:16:06 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
<47396A11.8020705@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
> However, what about the fact that some online resources (e.g. GenBank)
> will return several sorts of data (e.g. journal references and
> sequences) and/or in a range of file formats (e.g. GenBank, Fasta, XML,
> ...). In this situation, having the online interface separate from the
> format parsers makes some sense.
I agree. My suggestion would be
1) Split Bio.WWW.ExPASy (access to Swissprot, Prodoc, Prosite) between
Bio.SwissProt, Bio.Prosite, and Bio.Prodoc as appropriate
2) Put Bio.WWW.InterPro in Bio.InterPro
3) Put Bio.WWW.SCOP in Bio.SCOP
4) NCBI Entrez is a special case since it contains many different sorts of
data. Bio.GenBank doesn't seem to be the best place for it, as NCBI Entrez is
much more than GenBank. I would therefore suggest to move Bio.WWW.NCBI to
Bio.Entrez (currently an empty module in Biopython), and merge this code with
the database access code in Bio.GenBank and Bio.EUtils.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From mdehoon at c2b2.columbia.edu Wed Nov 14 02:16:06 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 13 Nov 2007 21:16:06 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu>
<47396A11.8020705@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
> However, what about the fact that some online resources (e.g. GenBank)
> will return several sorts of data (e.g. journal references and
> sequences) and/or in a range of file formats (e.g. GenBank, Fasta, XML,
> ...). In this situation, having the online interface separate from the
> format parsers makes some sense.
I agree. My suggestion would be
1) Split Bio.WWW.ExPASy (access to Swissprot, Prodoc, Prosite) between
Bio.SwissProt, Bio.Prosite, and Bio.Prodoc as appropriate
2) Put Bio.WWW.InterPro in Bio.InterPro
3) Put Bio.WWW.SCOP in Bio.SCOP
4) NCBI Entrez is a special case since it contains many different sorts of
data. Bio.GenBank doesn't seem to be the best place for it, as NCBI Entrez is
much more than GenBank. I would therefore suggest to move Bio.WWW.NCBI to
Bio.Entrez (currently an empty module in Biopython), and merge this code with
the database access code in Bio.GenBank and Bio.EUtils.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3245 bytes
Desc: not available
URL:
From chris.lasher at gmail.com Wed Nov 14 04:01:55 2007
From: chris.lasher at gmail.com (Chris Lasher)
Date: Tue, 13 Nov 2007 23:01:55 -0500
Subject: [Biopython-dev] Biopython SVN Transition
In-Reply-To: <4739775A.1020208@maubp.freeserve.co.uk>
References: <128a885f0710300717p7d91a4adjfaddc9c496974e67@mail.gmail.com>
<47278655.8090300@maubp.freeserve.co.uk>
<128a885f0710302255y4c34ac8axa48f48b253d5854a@mail.gmail.com>
<4739775A.1020208@maubp.freeserve.co.uk>
Message-ID: <128a885f0711132001j3d4c7c3aj1c1e255c66acd634@mail.gmail.com>
On Nov 13, 2007 5:07 AM, Peter wrote:
> Chris Lasher wrote:
> >> In terms of timing, how long do you/the OBF guys expect the transfer to
> >> take? And would they prefer to do this over a weekend or mid week?
> >
> > Not sure, let me ask Jason Stajich.
> > ...
> > I think we could expect less than a full day downtime.
>
> Any preference on mid week versus weekend? I'm still happy with any time
> in the next fortnight.
I haven't gotten in touch with Jason on this. Let me see what works for him.
> >> P.S. Would you or any of the people doing the transition be able to sort
> >> out bug 2363?
> >> http://bugzilla.open-bio.org/show_bug.cgi?id=2363
> >
> > That's a very good question. I wonder if cvs2svn is capable of picking
> > up those errors in commits and choose the proper format. I had trouble
> > getting a hold of an expert who could tell me how to identify files
> > committed as binary files, and how to change that to text (or vice
> > versa). I should send an email to the Subversion mailing list,
> > perhaps, or the CVS list if it's still active. I'll also check to see
> > if Jason knows.
>
> If you can solve this, it would make life easier for building from
> source on Windows :)
cvs status actually reveals this--any item marked with the following
"""
Sticky Options: -kb
"""
Was checked in as binary. To un-binary it, I guess we remove this property.
Chris
From bugzilla-daemon at portal.open-bio.org Wed Nov 14 09:17:37 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 14 Nov 2007 04:17:37 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711140917.lAE9HbTO023884@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-14 04:17 EST -------
In an email Eric Gibert wrote:
> MySQL does not commit the transaction by default and autocommit
> is not so advisable to ensure the database integrity. Thus we
> could include a .adaptor.commit() at the end of the
> following functions:
>
> Loader.py: load_seqrecord and remove
> BioSeqDatabase: DBServer.remove_database, new_database, load_database_sql
> BioSeqDatabase.Load (which might be redundant with commit in Loader)
I had also been wondering about something like this.
However, We need to think about the other database engines not just MySQL. And
we need to think about how this would affect anyone trying to use SQL
transactions.
Also, doing a commit in Loader.py's load() method after all the records, might
be better than in load_seqrecord() after each record. That way we should load
either all the records or none. Otherwise if the process fails half way, we
would have only half the records commited and that would be more difficult for
the user to sort out.
--
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.
From mdehoon at c2b2.columbia.edu Wed Nov 14 09:35:29 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Wed, 14 Nov 2007 04:35:29 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu> <47396A11.8020705@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
<473AB8A6.3050200@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B65F@mail2.exch.c2b2.columbia.edu>
> When you say move, do you mean just move - which will break existing
> scripts, or perhaps copy the stuff and mark the old version depreciated?
I was thinking to move the code itself, and let the function in the old
module call the function in the new module, after a DeprecationWarning.
> P.S. Is this sort of large scale rearrangement the sort of changes SVN
> is meant to track better than CVS?
Hopefully. One problem with CVS is that directories cannot be removed easily.
I hope that that will be easier with SVN.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From biopython-dev at maubp.freeserve.co.uk Wed Nov 14 08:58:14 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Wed, 14 Nov 2007 08:58:14 +0000
Subject: [Biopython-dev] Bio.WWW; database access
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu> <47396A11.8020705@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
Message-ID: <473AB8A6.3050200@maubp.freeserve.co.uk>
Michiel De Hoon wrote:
>> However, what about the fact that some online resources (e.g. GenBank)
>> will return several sorts of data (e.g. journal references and
>> sequences) and/or in a range of file formats (e.g. GenBank, Fasta, XML,
>> ...). In this situation, having the online interface separate from the
>> format parsers makes some sense.
>
> I agree. My suggestion would be
>
> 1) Split Bio.WWW.ExPASy (access to Swissprot, Prodoc, Prosite) between
> Bio.SwissProt, Bio.Prosite, and Bio.Prodoc as appropriate
> 2) Put Bio.WWW.InterPro in Bio.InterPro
> 3) Put Bio.WWW.SCOP in Bio.SCOP
> 4) NCBI Entrez is a special case since it contains many different sorts of
> data. Bio.GenBank doesn't seem to be the best place for it, as NCBI Entrez is
> much more than GenBank. I would therefore suggest to move Bio.WWW.NCBI to
> Bio.Entrez (currently an empty module in Biopython), and merge this code with
> the database access code in Bio.GenBank and Bio.EUtils.
>
> --Michiel.
That organisation sounds fine.
When you say move, do you mean just move - which will break existing
scripts, or perhaps copy the stuff and mark the old version depreciated?
P.S. Is this sort of large scale rearrangement the sort of changes SVN
is meant to track better than CVS?
Peter
From bugzilla-daemon at portal.open-bio.org Wed Nov 14 15:16:36 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 14 Nov 2007 10:16:36 -0500
Subject: [Biopython-dev] [Bug 2396] BioSQL loader does not store sequence
level annotations dict
In-Reply-To:
Message-ID: <200711141516.lAEFGaJI009957@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
------- Comment #2 from ericgibert at yahoo.fr 2007-11-14 10:16 EST -------
(From update of attachment 806)
I included the code provided in Loader.py and tested it successfully: 3 new
entries are now added to annotations after creation of a sequence from NCBI:
> 'source': ['mitochondrion Misagria parana '],
> 'sequence_version': ['1'] ,
> 'date': ['01-MAY-2006']
(curiously, we also have 'dates': ['01-MAY-2006']... ).
Anyway, this code seams quite good.
--
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.
From chris.lasher at gmail.com Thu Nov 15 20:39:15 2007
From: chris.lasher at gmail.com (Chris Lasher)
Date: Thu, 15 Nov 2007 15:39:15 -0500
Subject: [Biopython-dev] Biopython SVN Transition
In-Reply-To: <128a885f0711132001j3d4c7c3aj1c1e255c66acd634@mail.gmail.com>
References: <128a885f0710300717p7d91a4adjfaddc9c496974e67@mail.gmail.com>
<47278655.8090300@maubp.freeserve.co.uk>
<128a885f0710302255y4c34ac8axa48f48b253d5854a@mail.gmail.com>
<4739775A.1020208@maubp.freeserve.co.uk>
<128a885f0711132001j3d4c7c3aj1c1e255c66acd634@mail.gmail.com>
Message-ID: <128a885f0711151239m682ef82cnfb393241b2922468@mail.gmail.com>
On Nov 13, 2007 11:01 PM, Chris Lasher wrote:
> cvs status actually reveals this--any item marked with the following
> """
> Sticky Options: -kb
> """
>
> Was checked in as binary. To un-binary it, I guess we remove this property.
I found only four such files, at least under the Python code
directories of Biopython, and all were pickle files. So perhaps we
really don't have any files checked in as binary that shouldn't be?
Chris
From bugzilla-daemon at portal.open-bio.org Thu Nov 15 23:03:15 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 15 Nov 2007 18:03:15 -0500
Subject: [Biopython-dev] [Bug 2363] Some python files not stored as plain
text in CVS?
In-Reply-To:
Message-ID: <200711152303.lAFN3FDB032238@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2363
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |minor
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-15 18:03 EST -------
I think I've fixed some of these python files, having checked CVS stores them
as plain text, by correcting the newlines on Windows and committing the revised
version.
The unit tests affected seem OK now.
--
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.
From biopython-dev at maubp.freeserve.co.uk Sat Nov 17 22:33:41 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Sat, 17 Nov 2007 22:33:41 +0000
Subject: [Biopython-dev] Making mxTextTools an optional dependency in
setup.py
Message-ID: <320fb6e00711171433g2be36daatf7d8a64cad23d550@mail.gmail.com>
I'd like to update setup.py to make mxTextTools optional for
installing Biopython (the same status as ReportLab and Numeric). We
can still encourage people to install it for those part of Biopython
which do still use it, but I think a good proportion doesn't need it
anymore.
Any comments?
Peter
From mdehoon at c2b2.columbia.edu Mon Nov 19 01:23:06 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Sun, 18 Nov 2007 20:23:06 -0500
Subject: [Biopython-dev] Making mxTextTools an optional dependency
insetup.py
References: <320fb6e00711171433g2be36daatf7d8a64cad23d550@mail.gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B662@mail2.exch.c2b2.columbia.edu>
The fewer dependencies, the merrier; having two mxTextTools versions makes
this dependency even trickier. I am not sure though how much of Biopython
needs mxTextTools.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
-----Original Message-----
From: biopython-dev-bounces at lists.open-bio.org on behalf of Peter
Sent: Sat 11/17/2007 5:33 PM
To: BioPython Developers List
Subject: [Biopython-dev] Making mxTextTools an optional dependency insetup.py
I'd like to update setup.py to make mxTextTools optional for
installing Biopython (the same status as ReportLab and Numeric). We
can still encourage people to install it for those part of Biopython
which do still use it, but I think a good proportion doesn't need it
anymore.
Any comments?
Peter
_______________________________________________
Biopython-dev mailing list
Biopython-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biopython-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3373 bytes
Desc: not available
URL:
From mdehoon at c2b2.columbia.edu Mon Nov 19 02:33:11 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Sun, 18 Nov 2007 21:33:11 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu> <47396A11.8020705@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
<473AB8A6.3050200@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65F@mail2.exch.c2b2.columbia.edu>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B663@mail2.exch.c2b2.columbia.edu>
In my local copy of Biopython, I have now moved the SCOP database access code
from Bio/WWW/SCOP.py to Bio/SCOP/__init__.py. This are the functions "search"
and "_open" (which is an internally used function), both of which will for
the time being also be available (with a deprecation warning) from
Bio.WWW.SCOP. Any final objections before I upload this to CVS?
When SCOP is done, I'll start on moving Bio.WWW.InterPro to Bio.InterPro.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 09:00:27 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 04:00:27 -0500
Subject: [Biopython-dev] [Bug 2403] New: prosite parser can't handle new
PROSITE/PRORULE format
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
Summary: prosite parser can't handle new PROSITE/PRORULE format
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Main Distribution
AssignedTo: biopython-dev at biopython.org
ReportedBy: holger.dinkel at gmail.com
Prosite introduced a new field called ProRules which cause errors
in parsing with Bio/Prosite/__init__.py / Bio/ParserSupport.py.
The error applies to 1.42 and 1.44.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 09:02:16 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 04:02:16 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711190902.lAJ92GHa022134@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #1 from holger.dinkel at gmail.com 2007-11-19 04:02 EST -------
Created an attachment (id=812)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=812&action=view)
Test-Case PROSITE.DAT to reproduce the error
This is the first couple of lines of a prosite.dat (version 20) with prorule
entries to reproduce the error...
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 09:04:23 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 04:04:23 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711190904.lAJ94Nsv022557@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #2 from holger.dinkel at gmail.com 2007-11-19 04:04 EST -------
Created an attachment (id=813)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=813&action=view)
script to demonstrate the error
This script tries to parse the attached 'prosite_test.dat' and produces the
described error.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 10:38:48 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 05:38:48 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711191038.lAJAcmhW026808@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |biopython-
| |bugzilla at maubp.freeserve.co.
| |uk
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 05:38 EST -------
Confirming bug, I'll take a look at this now.
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.
From biopython at maubp.freeserve.co.uk Mon Nov 19 10:44:17 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 10:44:17 +0000
Subject: [Biopython-dev] Next release (was re: bug 2993)
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B661@mail2.exch.c2b2.columbia.edu>
References: <8fc5e4c20711161326q27723a16re5eca3de82573f8e@mail.gmail.com> <320fb6e00711161338w73f8e7d1l964671208e263ba3@mail.gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B661@mail2.exch.c2b2.columbia.edu>
Message-ID: <47416901.1070204@maubp.freeserve.co.uk>
Michiel De Hoon wrote:
> It's probably a good idea to make a new Biopython release in the near
> future, after fixing this bug [2393, Bio.GenBank.NCBIDictionary fails
> with release 1.44].
I would agree another release would be a good idea - but did you mean
you wanted to "fix" bug 2393 by avoiding Bio.config.DBRegistry, or just
go with my "one line fix" for now?
We should also check what state Tiago's Coalescent support through
Simcoal2 is at: http://bugzilla.open-bio.org/show_bug.cgi?id=2375
And, do you want to "tidy" up Bio.WWW before or after this new release?
I would vote for before - but we can add a warning to the release notes
that this is coming.
Peter
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 11:40:34 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 06:40:34 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711191140.lAJBeYGG030123@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #4 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 06:40 EST -------
Fixed in CVS, and I've also updated the unit test. Having the test data file
and example script all ready made this much easier, thanks.
As per my email, the order in _scan_fns does matter. The 'redundancy' you
spotted was commented as an ugly hack.
P.S. I would have used the following style in your script:
handle = open(PROSITEDAT)
iterator = Iterator(handle,RecordParser())
for record in iterator :
print record.name
prosite_data.append(record)
handle.close()
rather than:
handle = open(PROSITEDAT)
iterator = Iterator(handle,RecordParser())
record = iterator.next()
prosite_data = []
while record:
print record.name
prosite_data.append(record)
record = iterator.next()
handle.close()
--
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.
From tiagoantao at gmail.com Mon Nov 19 15:00:38 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Mon, 19 Nov 2007 15:00:38 +0000
Subject: [Biopython-dev] Accessing built-in data files
Message-ID: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
Hi,
The following mail documents my effort in understanding what needs to
be done in order to include data files with biopython. This serves to
purposes:
1. For review by others
2. For future reference, to anyone that needs to package data with the
distribution.
The problem can be split into 2 parts
1. Including the data with the distribution
2. Accessing the data that was packaged
The second is more complicated than the first.
1. Including the data with the distribution
Biopython uses distutils, a standard Python package mechanism. To
include data files, setup.py needs to be changed.
I recommend reading chapter 2 of the distutils manual
http://docs.python.org/dist/dist.html . Especially "Installing Package
Data" and "Installing Additional Files". I am using the "Package Data"
part.
In this scenario, the data files are placed alongside with the code in
the code directory (or, best, in a data subdirectory below).
To make this work setup.py needs to be changed. The change seems to be
trivial: Go to DATA_FILES and include your files. For SimCoal I did
this:
DATA_FILES=[
#.... More stuff will be here for other packages
"Bio/PopGen/SimCoal/data/*par" #my data files are *par
]
Thats it! Of course, as usual, the package should have been added (but
that is true to all packages)
2. Accessing the data that was packaged
This one is trickier. The first problem is that the data files might
be installed in either the platform dependent install directory or in
the platform independent one. With biopython this is actually a
non-problem, as data seems to go to the platform independent
directory. Which I suppose is the correct thing to do.
Now, the typical strategy is to get the sys.prefix to get the
directory where the platform independent files are installed (really
bad would be to get sys.exec_prefix which gets the platform dependent
path) and to append the package specific part. The problem is that, in
some cases (e.g. typical development cycle or when one doesn't have
admin install privileges on the computer), the installation is done to
another directory other than the system-wide default. My work around?
Go through all the directories on sys.path (PYTHONPATH) and search for
a data file that I know is there (because we know the path relative to
root of the installation, as on DATA_FILES above). When that file is
found, then the directory where all stuff is, is found. Not perfect,
but works for now.
Here is possible code to go to, e.g., __init__.py, of a package (based
on my SimCoal example):
---CODE STARTS---
from os import sep
from sys import path
for entry in path:
try:
#Searching for a single case, to determine correct directory
try_path = sep.join([entry, 'Bio', 'PopGen', 'SimCoal', 'data',
'island.par'])
f = open(try_path)
builtin_template_path = try_path
del try_path
f.close()
break
except:
pass #Correct behavior, searching for entry
---CODE ENDS---
One could raise an error if not found.
Comments?
Regards,
Tiago
--
http://www.tiago.org/ps
From biopython at maubp.freeserve.co.uk Mon Nov 19 15:25:48 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 15:25:48 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
Message-ID: <4741AAFC.70304@maubp.freeserve.co.uk>
Tiago Ant?o wrote:
> 1. Including the data with the distribution
> Biopython uses distutils, a standard Python package mechanism. To
> include data files, setup.py needs to be changed. ...
> Go to DATA_FILES and include your files. For SimCoal I did
> this:
> DATA_FILES=[
> #.... More stuff will be here for other packages
> "Bio/PopGen/SimCoal/data/*par" #my data files are *par
> ]
> Thats it! Of course, as usual, the package should have been added (but
> that is true to all packages)
Good.
> 2. Accessing the data that was packaged
> This one is trickier. The first problem is that the data files might
> be installed in either the platform dependent install directory or in
> the platform independent one. ...
I may be naive here, but I would expect the datafiles to be installed in
the same relative path as the python files. Is this not always the case?
As I pointed out in bug 2375, there is some code in setup.py (pre-dating
the support in distutils) which takes care of installing data files for
EUtils - if that actually works for the special cases you are concerned
about, maybe we should just use that for your data files too. See
http://bugzilla.open-bio.org/show_bug.cgi?id=2375
> My work around? Go through all the directories on sys.path (PYTHONPATH) and search for
> a data file that I know is there ...
That doesn't seem very elegant :(
Peter
From tiagoantao at gmail.com Mon Nov 19 15:41:57 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Mon, 19 Nov 2007 15:41:57 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <4741AAFC.70304@maubp.freeserve.co.uk>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
<4741AAFC.70304@maubp.freeserve.co.uk>
Message-ID: <6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
On Nov 19, 2007 3:25 PM, Peter wrote:
> > 2. Accessing the data that was packaged
> > This one is trickier. The first problem is that the data files might
> > be installed in either the platform dependent install directory or in
> > the platform independent one. ...
>
> I may be naive here, but I would expect the datafiles to be installed in
> the same relative path as the python files. Is this not always the case?
Yep, but which datafiles and where? By which I mean, platform
dependent or platform independent. Again this is mainly a not issue.
But "where" is important. "Where" might be the system path and all is
fine and dandy, but it also might be elsewhere (In my case, when
testing I don't install to the system path. Also, if you don't have
admin access to the machine...)
>
> As I pointed out in bug 2375, there is some code in setup.py (pre-dating
> the support in distutils) which takes care of installing data files for
> EUtils - if that actually works for the special cases you are concerned
> about, maybe we should just use that for your data files too. See
> http://bugzilla.open-bio.org/show_bug.cgi?id=2375
I checked that. I don't think (as far as I researched) that the data
is really accessed at execution.
DTDs (you can check the DTDs directory inside EUtils) were converted
to py files. And the data directory is actually a python module
directory (the generated py code is on CVS, actually).
> > My work around? Go through all the directories on sys.path (PYTHONPATH) and search for
> > a data file that I know is there ...
>
> That doesn't seem very elegant :(
I know, that is one of the reasons I called it "work around" and I am
discussing this in the open.
The changes to setup.py are quite trivial and pacific. But at the code
level I cannot think of a better solution. All that occurs to me is:
1. Use sys.prefix. Clean but that would mean only installations to the
system directory. I don't think that that is acceptable
2. The current solution
3. If there was a way to know where the package code is installed, I
could infer the data directory from there (clean, precise and robust),
but I don't know how to do that (if there is a way at all). That would
sort things out.
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 15:54:32 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 10:54:32 -0500
Subject: [Biopython-dev] [Bug 2390] Error importing Swiss Prot in BioSQL
In-Reply-To:
Message-ID: <200711191554.lAJFsWf7015661@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2390
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #18 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 10:54 EST -------
Marking as fixed - using CVS this now works for me with MySQL (subject to
manually doing a commit as per bug 2396).
P.S. There was a cut and past error in my sample code in comment 15, note that
Bio.SeqIO just wraps the Bio.SwissProt parser so this is pretty much equivalent
to Jon's original example.
#Run this in the Biopython/Tests/SwissProt directory
from BioSQL import BioSeqDatabase
from Bio import SeqIO
import os
server = BioSeqDatabase.open_database(driver='MySQLdb', user='root', passwd='',
host='localhost', db='bioseqdb')
db = server.new_database('bug2390')
for filename in os.listdir(".") :
if filename[:2]=="sp" :
print "Loading %s" % filename
db.load(SeqIO.parse(open(filename), "swiss"))
print "Committing..."
server.adaptor.commit()
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 15:59:37 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 10:59:37 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711191559.lAJFxbqK016012@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #8 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 10:59 EST -------
Do you want to mark this bug as fixed (with the one line import change), and
tackle rationalising Bio.config.DBRegistry, Bio.WWW etc separately?
Are you happy for me to check in that suggested unit test?
(test_SeqIO_online.py - attachment 805 on this bug)
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From tiagoantao at gmail.com Mon Nov 19 16:05:13 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Mon, 19 Nov 2007 16:05:13 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <4741B12E.9070909@maubp.freeserve.co.uk>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
<4741AAFC.70304@maubp.freeserve.co.uk>
<6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
<4741B12E.9070909@maubp.freeserve.co.uk>
Message-ID: <6d941f120711190805i5aa68392k62598d787567f079@mail.gmail.com>
> If the data files are installed the data subdirectory of where your
> python are, can't your python files just load them using a relative path?
Relative to what? The current directory is where the user is (not the
biopython directory). I don't know where the biopython code is (read
below), as such I cannot compute a path relative to it.
> Am I missing something?
The question is: How do I determine where biopython is installed? Is
that possible from inside the running code, in runtime? If yes, then
all is sorted (I just don't know how to do that), if no then I can
only think of transversing the whole PYTHONPATH.
Yes, it should be relative to the code path - I agree with you. But
how one finds where the code is (from a bunch of possible
alternatives) in runtime?
--
http://www.tiago.org/ps
From tiagoantao at gmail.com Mon Nov 19 16:42:46 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Mon, 19 Nov 2007 16:42:46 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <4741B8CD.1020103@maubp.freeserve.co.uk>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
<4741AAFC.70304@maubp.freeserve.co.uk>
<6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
<4741B12E.9070909@maubp.freeserve.co.uk>
<6d941f120711190805i5aa68392k62598d787567f079@mail.gmail.com>
<4741B8CD.1020103@maubp.freeserve.co.uk>
Message-ID: <6d941f120711190842y757b8d64m1516d82b185bf6d@mail.gmail.com>
> I think the answer is python's __file__ which will give the filename of
> the module (relative to the current working directory it would seem).
Spot on, thanks
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 16:57:43 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 11:57:43 -0500
Subject: [Biopython-dev] [Bug 19] implement dbsearch Registry
In-Reply-To:
Message-ID: <200711191657.lAJGvhkO020116@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=19
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|jchang at biopython.org |biopython-dev at biopython.org
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 11:57 EST -------
Should we mark this very old bug as a "won't fix"?
Or could someone explain in more detail what the plan here was?
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 17:22:16 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 12:22:16 -0500
Subject: [Biopython-dev] [Bug 1987] Alphabet.Gapped does not retain gap
character
In-Reply-To:
Message-ID: <200711191722.lAJHMGls021340@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=1987
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 12:22 EST -------
Having thought about this on and off for a while, I can't see any reason not to
deal with this bug. Fixed in CVS, Bio/Alphabet/__init__.py revision 1.7
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 19 17:28:13 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 12:28:13 -0500
Subject: [Biopython-dev] [Bug 1982] Patch to BioSQL/Loader.py
In-Reply-To:
Message-ID: <200711191728.lAJHSDQw021855@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=1982
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #4 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 12:28 EST -------
Given this was checked in months ago, with no new comments, I'm marking this as
fixed.
Note that earlier today I updated BioSQL to retrieve the db_xref data for
SeqFeatures from the database - the old code only stored this information in
the databse.
--
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.
From biopython at maubp.freeserve.co.uk Mon Nov 19 15:52:14 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 15:52:14 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com> <4741AAFC.70304@maubp.freeserve.co.uk>
<6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
Message-ID: <4741B12E.9070909@maubp.freeserve.co.uk>
Tiago Ant?o wrote:
>> I may be naive here, but I would expect the datafiles to be installed in
>> the same relative path as the python files. Is this not always the case?
>
> Yep, but which datafiles and where? By which I mean, platform
> dependent or platform independent. Again this is mainly a not issue.
> But "where" is important. "Where" might be the system path and all is
> fine and dandy, but it also might be elsewhere (In my case, when
> testing I don't install to the system path. Also, if you don't have
> admin access to the machine...)
If the data files are installed the data subdirectory of where your
python are, can't your python files just load them using a relative path?
e.g. On Windows, using Python 2.3 (from memory) the files should go:
C:\Python23\lib\site-packages\Bio\PopGen\SimCoal\*.py
C:\Python23\lib\site-packages\Bio\PopGen\SimCoal\data\*.par
On my linux machine, where I have installed Biopython under my home
directory (rather than system wide):
~/lib/python2.4/site-packages/Bio/PopGen/SimCoal/*.py
~/lib/python2.4/site-packages/Bio/PopGen/SimCoal/data/*.par
If I had installed Biopython using admin access, it might be:
/usr/lib/python2.4/site-packages/Bio/PopGen/SimCoal/*.py
/usr/lib/python2.4/site-packages/Bio/PopGen/SimCoal/data/*.par
In all those cases, one of your SimCoal python files just needs to open
its data files using a relative path, for example "data/island.par".
For comparison, the EUtils DTD files did end up here as I expected:
~/lib/python2.4/site-packages/Bio/EUtils/DTDs/*.dtd
Am I missing something?
Peter
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 00:51:28 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 19:51:28 -0500
Subject: [Biopython-dev] [Bug 2393] Bio.GenBank.NCBIDictionary fails with
release 1.44
In-Reply-To:
Message-ID: <200711200051.lAK0pShp012213@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2393
------- Comment #9 from mdehoon at ims.u-tokyo.ac.jp 2007-11-19 19:51 EST -------
> Do you want to mark this bug as fixed (with the one line import change), and
> tackle rationalising Bio.config.DBRegistry, Bio.WWW etc separately?
I'd leave this bug open for now, since the one line import change causes a
DeprecationWarning. Treating the rationalisation of Bio.config.DBRegistry,
Bio.WWW etc as a separate issue is fine with me. Once we have a solution for
that, fixing Bio.GenBank.NCBIDictionary will be trivial.
> Are you happy for me to check in that suggested unit test?
> (test_SeqIO_online.py - attachment 805 [details] on this bug)
That is fine with me.
--
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 00:52:19 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 19:52:19 -0500
Subject: [Biopython-dev] [Bug 19] implement dbsearch Registry
In-Reply-To:
Message-ID: <200711200052.lAK0qJFe012265@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=19
------- Comment #2 from mdehoon at ims.u-tokyo.ac.jp 2007-11-19 19:52 EST -------
"won't fix" sounds reasonable to me.
--
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.
From mdehoon at c2b2.columbia.edu Tue Nov 20 00:53:41 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Mon, 19 Nov 2007 19:53:41 -0500
Subject: [Biopython-dev] Next release (was re: bug 2993)
References: <8fc5e4c20711161326q27723a16re5eca3de82573f8e@mail.gmail.com> <320fb6e00711161338w73f8e7d1l964671208e263ba3@mail.gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B661@mail2.exch.c2b2.columbia.edu>
<47416901.1070204@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B665@mail2.exch.c2b2.columbia.edu>
> Michiel De Hoon wrote:
> > It's probably a good idea to make a new Biopython release in the near
> > future, after fixing this bug [2393, Bio.GenBank.NCBIDictionary fails
> > with release 1.44].
>
> I would agree another release would be a good idea - but did you mean
> you wanted to "fix" bug 2393 by avoiding Bio.config.DBRegistry, or just
> go with my "one line fix" for now?
The "one line fix" is OK for current users of Biopython 1.44, but since it
generates a DeprecationWarning I think it should not go into the next
release.
> And, do you want to "tidy" up Bio.WWW before or after this new release?
> I would vote for before - but we can add a warning to the release notes
> that this is coming.
I'd like to tidy up Bio.WWW before.
> We should also check what state Tiago's Coalescent support through
> Simcoal2 is at: http://bugzilla.open-bio.org/show_bug.cgi?id=2375
I expect that it will take a couple of weeks to tidy up Bio.WWW et al., so
hopefully there will be enough time for Tiago's Coalescent support to be
finished on time for the next release.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 01:31:17 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 19 Nov 2007 20:31:17 -0500
Subject: [Biopython-dev] [Bug 19] implement dbsearch Registry
In-Reply-To:
Message-ID: <200711200131.lAK1VHqU014193@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=19
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-19 20:31 EST -------
Resolving as "Won't Fix"
--
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.
From biopython at maubp.freeserve.co.uk Mon Nov 19 14:05:23 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 14:05:23 +0000
Subject: [Biopython-dev] BioSQL
Message-ID: <47419823.8040305@maubp.freeserve.co.uk>
Dear list members,
As some of you may have guessed from recent bug activity, I've got
BioSQL up and running on my machine, using MySQL. I've even made a
start at updating the documentation:
http://www.biopython.org/wiki/BioSQL
Annoyingly the unit test (test_BioSQL.py) wasn't working, but I believe
that I have fixed that now in CVS. If any of the other developers have
BioSQL setup, could you please check out the latest code and double
check this for me. If you use something other than MySQL that would be
of particular interest.
Also, comments on the MySQL commit issue in Bug 2395 welcome!
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
Peter
P.S. I've not yet sorted out bug 2396, I want to study how BioPerl
and/or BioJava handle this to make sure what ever I do is compatible.
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
From mdehoon at c2b2.columbia.edu Tue Nov 20 02:34:09 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Mon, 19 Nov 2007 21:34:09 -0500
Subject: [Biopython-dev] BioSQL
References: <47419823.8040305@maubp.freeserve.co.uk>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
With the Biopython currently in CVS, I get an error from test_BioSQL:
======================================================================
FAIL: test_BioSQL
----------------------------------------------------------------------
Traceback (most recent call last):
File "run_tests.py", line 151, in runTest
self.runSafeTest()
File "run_tests.py", line 188, in runSafeTest
expected_handle)
File "run_tests.py", line 289, in compare_output
"\nOutput : "+`output_line` + "\nExpected: "+`expected_line`
AssertionError:
Output : 'Load SeqRecord objects into a BioSQL database. ... ERROR\n'
Expected: 'Load SeqRecord objects into a BioSQL database. ... ok\n'
----------------------------------------------------------------------
If I run test_BioSQL.py directly, I expect to get a
Bio.MissingExternalDependencyError (as with Biopython 1.44):
Traceback (most recent call last):
File "test_BioSQL.py", line 40, in
raise Bio.MissingExternalDependencyError(message)
Bio.MissingExternalDependencyError: Enable tests in Tests/test_BioSQL.py (not
im
portant if you do not plan to use BioSQL).
---------------------------------------------------------------------------
With Biopython now in CVS, test_BioSQL.py generates the following output:
$ python test_BioSQL.py
Load SeqRecord objects into a BioSQL database. ... ERROR
Get a list of all items in the database. ... ERROR
Test retrieval of items using various ids. ... ERROR
Make sure Seqs from BioSQL implement the right interface. ... ERROR
Check SeqFeatures of a sequence. ... ERROR
Make sure SeqRecords from BioSQL implement the right interface. ... ERROR
Check that slices of sequences are retrieved properly. ... ERROR
Make sure all records are correctly loaded. ... ERROR
Indepth check that SeqFeatures are transmitted through the db. ... ERROR
======================================================================
ERROR: Load SeqRecord objects into a BioSQL database.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 275, in setUp
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Get a list of all items in the database.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 128, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Test retrieval of items using various ids.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 128, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Make sure Seqs from BioSQL implement the right interface.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 179, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Check SeqFeatures of a sequence.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 179, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Make sure SeqRecords from BioSQL implement the right interface.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 179, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Check that slices of sequences are retrieved properly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 179, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Make sure all records are correctly loaded.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 329, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
======================================================================
ERROR: Indepth check that SeqFeatures are transmitted through the db.
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_BioSQL.py", line 329, in setUp
load_database(gb_handle)
File "test_BioSQL.py", line 102, in load_database
create_database()
File "test_BioSQL.py", line 56, in create_database
host = DBHOST)
File "/usr/lib/python2.5/site-packages/BioSQL/BioSeqDatabase.py", line 28,
in
open_database
module = __import__(driver)
File "build/bdist.cygwin-1.5.24-i686/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
__bootstrap__
ImportError: Permission denied
----------------------------------------------------------------------
Ran 9 tests in 0.140s
FAILED (errors=9)
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
-----Original Message-----
From: biopython-dev-bounces at lists.open-bio.org on behalf of Peter
Sent: Mon 11/19/2007 9:05 AM
To: biopython-dev at lists.open-bio.org
Subject: [Biopython-dev] BioSQL
Dear list members,
As some of you may have guessed from recent bug activity, I've got
BioSQL up and running on my machine, using MySQL. I've even made a
start at updating the documentation:
http://www.biopython.org/wiki/BioSQL
Annoyingly the unit test (test_BioSQL.py) wasn't working, but I believe
that I have fixed that now in CVS. If any of the other developers have
BioSQL setup, could you please check out the latest code and double
check this for me. If you use something other than MySQL that would be
of particular interest.
Also, comments on the MySQL commit issue in Bug 2395 welcome!
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
Peter
P.S. I've not yet sorted out bug 2396, I want to study how BioPerl
and/or BioJava handle this to make sure what ever I do is compatible.
http://bugzilla.open-bio.org/show_bug.cgi?id=2396
_______________________________________________
Biopython-dev mailing list
Biopython-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biopython-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5527 bytes
Desc: not available
URL:
From biopython at maubp.freeserve.co.uk Mon Nov 19 16:24:45 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Mon, 19 Nov 2007 16:24:45 +0000
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <6d941f120711190805i5aa68392k62598d787567f079@mail.gmail.com>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com> <4741AAFC.70304@maubp.freeserve.co.uk> <6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com> <4741B12E.9070909@maubp.freeserve.co.uk>
<6d941f120711190805i5aa68392k62598d787567f079@mail.gmail.com>
Message-ID: <4741B8CD.1020103@maubp.freeserve.co.uk>
Tiago Ant?o wrote:
>> If the data files are installed the data subdirectory of where your
>> python are, can't your python files just load them using a relative path?
>
> Relative to what? The current directory is where the user is (not the
> biopython directory). I don't know where the biopython code is (read
> below), as such I cannot compute a path relative to it.
>
> ...
>
> Yes, it should be relative to the code path - I agree with you. But
> how one finds where the code is (from a bunch of possible
> alternatives) in runtime?
I think the answer is python's __file__ which will give the filename of
the module (relative to the current working directory it would seem).
Peter
From sbassi at gmail.com Tue Nov 20 03:43:03 2007
From: sbassi at gmail.com (Sebastian Bassi)
Date: Tue, 20 Nov 2007 00:43:03 -0300
Subject: [Biopython-dev] Accessing built-in data files
In-Reply-To: <4741B12E.9070909@maubp.freeserve.co.uk>
References: <6d941f120711190700n18b02dcfk87fe89c6e16e0aa7@mail.gmail.com>
<4741AAFC.70304@maubp.freeserve.co.uk>
<6d941f120711190741l1cc863e5g16ee21482facaf2b@mail.gmail.com>
<4741B12E.9070909@maubp.freeserve.co.uk>
Message-ID:
On Nov 19, 2007 12:52 PM, Peter wrote:
> e.g. On Windows, using Python 2.3 (from memory) the files should go:
> C:\Python23\lib\site-packages\Bio\PopGen\SimCoal\*.py
...
That is the default option in Windows. But the installer gives the
user the choice to change the installation path.
--
Curso Biologia Molecular para programadores: http://tinyurl.com/2vv8w6
Bioinformatics news: http://www.bioinformatica.info
Lriser: http://www.linspire.com/lraiser_success.php?serial=318
From mdehoon at c2b2.columbia.edu Tue Nov 20 08:39:53 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 20 Nov 2007 03:39:53 -0500
Subject: [Biopython-dev] Bio.WWW; database access
References: <6243BAA9F5E0D24DA41B27997D1FD14402B65B@mail2.exch.c2b2.columbia.edu> <47396A11.8020705@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65E@mail2.exch.c2b2.columbia.edu>
<473AB8A6.3050200@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B65F@mail2.exch.c2b2.columbia.edu>
<6243BAA9F5E0D24DA41B27997D1FD14402B663@mail2.exch.c2b2.columbia.edu>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B668@mail2.exch.c2b2.columbia.edu>
Hi everybody,
I have now moved the database access code from Bio.WWW.SCOP and
Bio.WWW.InterPro to Bio.SCOP and Bio.InterPro, respectively.
This leaves us with Bio.WWW.NCBI and Bio.WWW.ExPASy.
The latter contains the following functions:
get_prodoc_entry Interface to the get-prodoc-entry CGI script.
get_prosite_entry Interface to the get-prosite-entry CGI script.
get_sprot_raw Interface to the get-sprot-raw.pl CGI script.
sprot_search_ful Interface to the sprot-search-ful CGI script.
sprot_search_de Interface to the sprot-search-de CGI script.
so it access Prodoc, Prosite, and SwissProt.
The corresponding parsers are in
Bio.Prosite.Prodoc for Prodoc
Bio.Prosite for Prosite
Bio.SwissProt.SProt for SwissProt
(each of these modules also contain some code to access Prodoc, Prosite,
SwissProt over the internet).
My question is: What is the preferred place to put the five functions from
Bio.WWW.ExPASy?
One option is to put get_prodoc_entry in Bio.Prosite.Prodoc,
get_prosite_entry in Bio.Prosite, and get_sprot_raw, sprot_search_ful, and
sprot_search_de in Bio.SwissProt.SProt (actually, I don't understand why we
have a Bio.SwissProt.SProt, since Bio.SwissProt.__init__ is currently empty,
but that's a different issue).
A second option is to have a separate Bio.ExPASy, so to simply rename
Bio.WWW.ExPAsy to Bio.ExPASy.
Any other options I haven't thought of?
I am leaning towards the first option. Any other opinions?
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From biopython-dev at maubp.freeserve.co.uk Tue Nov 20 10:13:35 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Tue, 20 Nov 2007 10:13:35 +0000
Subject: [Biopython-dev] BioSQL
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
References: <47419823.8040305@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
Message-ID: <320fb6e00711200213n5d78759bra006289f55a65992@mail.gmail.com>
Michiel De Hoon wrote:
> With the Biopython currently in CVS, I get an error from test_BioSQL:
Good point, I didn't try out the situation when the database wasn't
setup correctly.
> FAIL: test_BioSQL
> ...
> If I run test_BioSQL.py directly, I expect to get a
> Bio.MissingExternalDependencyError (as with Biopython 1.44):
> ...
> File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 7, in
> File "build/bdist.cygwin-1.5.24-i686/egg/_mysql.py", line 6, in
> __bootstrap__
> ImportError: Permission denied
I moved the password setup etc out of test_BioSQL.py into
setup_BioSQL.py (two reasons, one I didn't want to have to check
test_BioSQL.py was up to date by hand, and two, I plan to add more tests).
I guess the problem is the default settings I put in setup_BioSQL.py,
which previously were undefined. These settings work for me, as
described on http://www.bioperl.org/wiki/BioSQL (new).
On your system, I guess that MySQL is available but the
username/password are wrong. If we revert these to being undefined,
then the test should fail as before with MissingExternalDependencyError.
Can you check that easily? I should probably add an error handler to
look for permission denied too...
Peter
From mdehoon at c2b2.columbia.edu Tue Nov 20 10:26:02 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Tue, 20 Nov 2007 05:26:02 -0500
Subject: [Biopython-dev] BioSQL
References: <47419823.8040305@maubp.freeserve.co.uk><6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
<320fb6e00711200213n5d78759bra006289f55a65992@mail.gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B669@mail2.exch.c2b2.columbia.edu>
> On your system, I guess that MySQL is available but the
> username/password are wrong. If we revert these to being undefined,
> then the test should fail as before with MissingExternalDependencyError.
>
> Can you check that easily? I should probably add an error handler to
> look for permission denied too...
If I comment out DBDRIVER and DBTYPE in setup_BioSQL.py, then the test fails
with a MissingExternalDependencyError as before.
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From biopython-dev at maubp.freeserve.co.uk Tue Nov 20 10:29:43 2007
From: biopython-dev at maubp.freeserve.co.uk (Peter)
Date: Tue, 20 Nov 2007 10:29:43 +0000
Subject: [Biopython-dev] BioSQL
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B669@mail2.exch.c2b2.columbia.edu>
References: <47419823.8040305@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B667@mail2.exch.c2b2.columbia.edu>
<320fb6e00711200213n5d78759bra006289f55a65992@mail.gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B669@mail2.exch.c2b2.columbia.edu>
Message-ID: <320fb6e00711200229m2af30809qc33c26d5bcfb14ed@mail.gmail.com>
> If I comment out DBDRIVER and DBTYPE in setup_BioSQL.py, then the test fails
> with a MissingExternalDependencyError as before.
Great. I'll fix that in CVS then. Can you configure things to
actually run the test?
Peter
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 12:30:51 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 07:30:51 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201230.lAKCUpXl017247@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #5 from holger.dinkel at gmail.com 2007-11-20 07:30 EST -------
Created an attachment (id=816)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=816&action=view)
fixed version (but with little hack; might not suit everybody)
There are still some errors thrown when scanning the whole prosite_20.dat:
Firstly, the Prosite-Team had also introduced a new field called
"postprocessing", so now the parser chokes on that.
And secondly the parser breaks at some special comment-lines with authornames
in it of the form "CC /AUTHOR=K_Hofmann; N_Hulo" (Prosite-Acc PS50293): The
comments are split into columns and then parsed into values at the
"="-letter. As Mr. Hulo does not have a "/Author=" prepended, an error is
raised...
I was able to fix the first problem straightforward as Peter did and inserted a
postprocessing-entry.
I could also solve the second problem, but only with some hack which might not
suit everybody:
First, i split the "qual, data = [word.lstrip() for word in col.split("=")]"
into two to avoid KeyErrors:
qual = [word.lstrip() for word in col.split("=")][0]
data = ''.join([word.lstrip() for word in col.split("=")][1:])
and then i introduced a hack to circumvent the aforementioned problem:
changed
if qual == '/TAXO-RANGE':
to
if qual == 'N_Hulo':
continue
elif qual == '/TAXO-RANGE':
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 12:33:14 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 07:33:14 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201233.lAKCXEGj017547@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #6 from holger.dinkel at gmail.com 2007-11-20 07:33 EST -------
Created an attachment (id=817)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=817&action=view)
patch with changes (but with little hack; might not suit everybody)
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 12:39:46 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 07:39:46 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201239.lAKCdkmx018187@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Comment #7 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-20 07:39 EST -------
Reopening bug.
Issue One:
PR lines (prorules), fixed.
Issue Two:
PP lines (post-processing)
See http://www.expasy.ch/prosite/psrelnot.html
Issue Three:
Funny CC lines, e.g. "CC /AUTHOR=K_Hofmann; N_Hulo" (Prosite-Acc PS50293)
See http://expasy.org/cgi-bin/get-prosite-raw.pl?PS50293
--
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.
From tiagoantao at gmail.com Tue Nov 20 12:42:36 2007
From: tiagoantao at gmail.com (=?ISO-8859-1?Q?Tiago_Ant=E3o?=)
Date: Tue, 20 Nov 2007 12:42:36 +0000
Subject: [Biopython-dev] Next release (was re: bug 2993)
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B665@mail2.exch.c2b2.columbia.edu>
References: <8fc5e4c20711161326q27723a16re5eca3de82573f8e@mail.gmail.com>
<320fb6e00711161338w73f8e7d1l964671208e263ba3@mail.gmail.com>
<6243BAA9F5E0D24DA41B27997D1FD14402B661@mail2.exch.c2b2.columbia.edu>
<47416901.1070204@maubp.freeserve.co.uk>
<6243BAA9F5E0D24DA41B27997D1FD14402B665@mail2.exch.c2b2.columbia.edu>
Message-ID: <6d941f120711200442i39ad6908ped89b8d1bd822fbd@mail.gmail.com>
On Nov 20, 2007 12:53 AM, Michiel De Hoon wrote:
> > We should also check what state Tiago's Coalescent support through
> > Simcoal2 is at: http://bugzilla.open-bio.org/show_bug.cgi?id=2375
>
> I expect that it will take a couple of weeks to tidy up Bio.WWW et al., so
> hopefully there will be enough time for Tiago's Coalescent support to be
> finished on time for the next release.
I will prioritize this in my task list in order to have it ready on
time. I don't expect any serious problems.
--
http://www.tiago.org/ps
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 13:29:41 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 08:29:41 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201329.lAKDTfDV020505@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #8 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-20 08:29 EST -------
Issue Two:
I've found an example with a PP line to test with, PS51192
http://expasy.org/cgi-bin/get-prosite-raw.pl?PS51192
Issue Three:
I think I've fixed the funny CC line problem with Bio/Prosite/__init__.py CVS
revision 1.15
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 13:39:34 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 08:39:34 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201339.lAKDdYRO021027@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
------- Comment #9 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-20 08:39 EST -------
Issue Two:
The PP lines problem should be fixed with with Bio/Prosite/__init__.py CVS
revision 1.15
Your patch was pretty close, you seem to have more or less understood how this
parser works :)
One problem I did notice was:
+ def _scan_pp(self, uhandle, consumer):
+ #New PP line, PostProcessing
+ self._scan_line('PP', uhandle, consumer.prorule, any_number=1)
Should have been:
+ def _scan_pp(self, uhandle, consumer):
+ #New PP line, PostProcessing
+ self._scan_line('PP', uhandle, consumer.postprocessing, any_number=1)
Otherwise any PP lines would get treated like PR lines!
Could you get the latest code, and confirm this works prosite.dat (version 20)?
There may be other quirks as I have only tried a few ProSite files myself...
Thank you, 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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 14:05:27 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 09:05:27 -0500
Subject: [Biopython-dev] [Bug 2403] prosite parser can't handle new
PROSITE/PRORULE format
In-Reply-To:
Message-ID: <200711201405.lAKE5RFA022593@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2403
holger.dinkel at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |holger.dinkel at gmail.com
Status|REOPENED |RESOLVED
Resolution| |FIXED
------- Comment #10 from holger.dinkel at gmail.com 2007-11-20 09:05 EST -------
Tested and confirmed.
Rev 1.16 of biopython/Bio/Prosite/__init__.py seems to work (tested on Prosite
V18-20) - at least it throws no exceptions ;->
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 18:49:32 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 13:49:32 -0500
Subject: [Biopython-dev] [Bug 2405] New: BioSQL gives UserWarning: ... not
recognised as database type: temporarily accepting key
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2405
Summary: BioSQL gives UserWarning: ... not recognised as database
type: temporarily accepting key
Product: Biopython
Version: 1.44
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
This can be demonstrated by the new unit test:
$python run_tests.py test_BioSQL_SeqIO.py
The test should pass, but prints lots of warnings to the console, e.g.:
.../BioSQL/Loader.py:500: UserWarning: LocusID not recognised as database type:
temporarily accepting key
warnings.warn("%s not recognised as database type: temporarily accepting key"
% key)
We need to update the dictionary (which is now) in BioSQL/__init__.py to cope
with these - but whatever mapping we use should be compatible with BioPerl,
BioJava, etc.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 20 22:50:29 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 17:50:29 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711202250.lAKMoTNg019776@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-20 17:50 EST -------
I'm begining to think this isn't a bug, its just a fact of life when dealing
with transactional databases - functionality that early versions of MySQL
lacked.
Either the user takes charge of the transactions, committing changes when they
see fit (e.g. after loading a file), or we enable auto-commit, or Biopython
trys to decide on its own - which risks getting it wrong. My current
preference is for explicit commits rather than implicit commits.
Comments welcome - especially from anyone using another database engine (e.g.
PostgreSQL)
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 21 02:53:21 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 20 Nov 2007 21:53:21 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711210253.lAL2rLEX000301@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
------- Comment #4 from ericgibert at yahoo.fr 2007-11-20 21:53 EST -------
Although I agree on principle that this is not a bug, I think that we should
look what BioPerl and BioJava are doing. In my experience, BioJava does commit
transactions (that is why I was "surprised" in the first place :-) )
This being said, I do not mind adding commits...
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 21 18:20:38 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 21 Nov 2007 13:20:38 -0500
Subject: [Biopython-dev] [Bug 2408] New: GenBank records do not contain U's
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2408
Summary: GenBank records do not contain U's
Product: Biopython
Version: 1.43
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Main Distribution
AssignedTo: biopython-dev at biopython.org
ReportedBy: marcin.cieslik at gmail.com
The GenBank GenBank.FeatureParser() assigns a wrong alphabet for ss-RNA
records:
all GenBank records use T's not U's:
http://www.bioperl.org/pipermail/bioperl-l/2001-October/006400.html
parsing of:
http://www.ncbi.nlm.nih.gov/entrez/viewer.fcgi?db=nuccore&id=511859
results in:
u'511859': SeqRecord(seq=Seq('CAC <> TGG', IUPACAmbiguousRNA()),
id='M23021.1', name='MSBMVCCG', description='Southern cowpea mosaic virus,
complete genome.', dbxrefs=[])}
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 22 00:25:15 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 21 Nov 2007 19:25:15 -0500
Subject: [Biopython-dev] [Bug 2408] GenBank records do not contain U's
In-Reply-To:
Message-ID: <200711220025.lAM0PFTu026818@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2408
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-21 19:25 EST -------
So the GenBank file says in its header "ss-RNA" (single stranded RNA), and we
obey this and set an RNA alphabet. However, as you point out, the actual
sequence contains T not U, so is in fact given as DNA!
Is this a bug in GenBank maybe...?
Do you think we should switch the T's into U's to match the stated alphabet, or
simply return a DNA sequence based on the content?
--
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.
From bugzilla-daemon at portal.open-bio.org Thu Nov 22 05:18:03 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Thu, 22 Nov 2007 00:18:03 -0500
Subject: [Biopython-dev] [Bug 2408] GenBank records do not contain U's
In-Reply-To:
Message-ID: <200711220518.lAM5I3rX003480@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2408
------- Comment #2 from marcin.cieslik at gmail.com 2007-11-22 00:18 EST -------
I don't believe there are any U-containing records in GenBank since it is DNA
whats being sequenced. mRNA records also have T's. I think assigning alphabets
based on parsed sequence is overkill. Since it will make it more difficult to
translate (ambigous vs. unambigous - Translator exceptions). I would like the
parser to return IUPAC.ambigous_dna, but that is just my preference and since i
can fix it by a single record.alphabet assignment it is not critical at all.
(In reply to comment #1)
> So the GenBank file says in its header "ss-RNA" (single stranded RNA), and we
> obey this and set an RNA alphabet. However, as you point out, the actual
> sequence contains T not U, so is in fact given as DNA!
>
> Is this a bug in GenBank maybe...?
>
> Do you think we should switch the T's into U's to match the stated alphabet, or
> simply return a DNA sequence based on the content?
>
--
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.
From bugzilla-daemon at portal.open-bio.org Sat Nov 24 09:22:39 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Sat, 24 Nov 2007 04:22:39 -0500
Subject: [Biopython-dev] [Bug 2405] BioSQL gives UserWarning: ... not
recognised as database type: temporarily accepting key
In-Reply-To:
Message-ID: <200711240922.lAO9Mdrc018429@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2405
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-24 04:22 EST -------
Based on talking to a couple of the BioPerl guys, they don't do any mapping of
the db_xref at all. I see two options:
(a) Continue with the historical mapping in Biopython, and simply remove the
warning.
(b) Remove the mapping, just store the raw NCBI supplied db_xref terminology.
(c) Remove the mapping, except when reading data from the database in order to
retain backwards compatibility with data written using older versions of
Biopython [may not be required; until I fixed it recently the db_xref wasn't
even loaded for SeqFeatures]
I favour option (b) because its simpler and more compatible with the other Bio*
projects.
--
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.
From bugzilla-daemon at portal.open-bio.org Sun Nov 25 12:26:35 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Sun, 25 Nov 2007 07:26:35 -0500
Subject: [Biopython-dev] [Bug 2405] BioSQL gives UserWarning: ... not
recognised as database type: temporarily accepting key
In-Reply-To:
Message-ID: <200711251226.lAPCQZ7P004332@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2405
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-25 07:26 EST -------
Created an attachment (id=826)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=826&action=view)
Patch to BioSQL/__init__.py, Loader.py and BioSeq.py
Removes the mapping of db_xref keys.
Both unit tests pass, test_BioSQL.py and test_BioSQL_SeqIO.py
Any comments/objections from the mailing list to this being committed?
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 20:57:42 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 15:57:42 -0500
Subject: [Biopython-dev] [Bug 2410] New: DBSeq & DBSeqRecord should subclass
Seq & SeqRecord
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2410
Summary: DBSeq & DBSeqRecord should subclass Seq & SeqRecord
Product: Biopython
Version: 1.44
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
The DBSeq and DBSeqRecord classes are defined in BioSQL/BioSeq.py
They attempt to implement the core API defined for the corresponding objects in
Bio.Seq and Bio.SeqRecord, via database wrappers which load and caches data on
demand. The idea being that the DBSeqRecord and DBSeq can be used
interchangeably with the classic SeqRecord with Seq.
The problem is they are lacking several useful methods including __str__ and
__repr__ (see changes made to the Seq object on Bug 2351) and other Seq object
methods like count, complement and reverse_complement (see also enhancement Bug
2381).
I propose to make DBSeq and DBSeqRecord subclass Seq and SeqRecord
respectively. Trivial patch to follow - the two BioSQL unit tests seem to pass
just fine.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 21:05:55 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 16:05:55 -0500
Subject: [Biopython-dev] [Bug 2351] Make Seq more like a string,
even subclass string?
In-Reply-To:
Message-ID: <200711262105.lAQL5t1c008299@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2351
------- Comment #14 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 16:05 EST -------
See also Bug 2410, there is a BioSQL DBSeq object which should be API
interchangeable with the Seq object. This would be another reason not to rush
into making Seq subclass the python string.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 21:05:58 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 16:05:58 -0500
Subject: [Biopython-dev] [Bug 2381] translate and transcibe methods for the
Seq object (in Bio.Seq)
In-Reply-To:
Message-ID: <200711262105.lAQL5wjp008318@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2381
------- Comment #10 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 16:05 EST -------
See also Bug 2410, there is a BioSQL DBSeq object which should be
interchangeable with the Seq object.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 21:15:08 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 16:15:08 -0500
Subject: [Biopython-dev] [Bug 2411] New: Slicing the DBSeq object (BioSQL's
Seq object)
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
Summary: Slicing the DBSeq object (BioSQL's Seq object)
Product: Biopython
Version: 1.44
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: BioSQL
AssignedTo: biopython-dev at biopython.org
ReportedBy: biopython-bugzilla at maubp.freeserve.co.uk
The BioSQL version of the Seq object, DBSeq, raises a IndexError when
__getitem__ is given a slice with a stride.
See also Bug 2348 - Slicing the Seq object (returns a string when use a stride)
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 21:34:26 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 16:34:26 -0500
Subject: [Biopython-dev] [Bug 2411] Element access and slicing of DBSeq
object (BioSQL's Seq object)
In-Reply-To:
Message-ID: <200711262134.lAQLYQAY009394@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Slicing the DBSeq object |Element access and slicing
|(BioSQL's Seq object) |of DBSeq object (BioSQL's
| |Seq object)
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 16:34 EST -------
It gets worse - the existing DBSeq's __getslice__ doesn't even like negative
start/stop. Retitling bug to cover this too.
I'm making progress here :)
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 22:14:02 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 17:14:02 -0500
Subject: [Biopython-dev] [Bug 2411] Element access and slicing of DBSeq
object (BioSQL's Seq object)
In-Reply-To:
Message-ID: <200711262214.lAQME27B011121@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
------- Comment #2 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 17:14 EST -------
The element access only failed with an IndexError when attempted to get the
zero element by using an index of the negative length (i.e. a corner case).
That is fixed in BioSQL/BioSeq.py revision 1.15
Updated unit test in Test/test_BioSQL_SeqIO.py revision 1.6 checks basic
element access and slicing with the DBSeq object - but does not yet attempt
slicing with a stride (step).
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 22:39:37 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 17:39:37 -0500
Subject: [Biopython-dev] [Bug 2411] Element access and slicing of DBSeq
object (BioSQL's Seq object)
In-Reply-To:
Message-ID: <200711262239.lAQMdbUt012266@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 17:39 EST -------
Fixed in CVS, see:
BioSQL/BioSeq.py revision 1.16
Tests/test_BioSQL_SeqIO.py revision: 1.7
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 23:28:10 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 18:28:10 -0500
Subject: [Biopython-dev] [Bug 2411] Element access and slicing of DBSeq
object (BioSQL's Seq object)
In-Reply-To:
Message-ID: <200711262328.lAQNSATe014236@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2411
------- Comment #4 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 18:28 EST -------
Make that:
BioSQL/BioSeq.py revision 1.17
Tests/test_BioSQL_SeqIO.py revision: 1.8
I missed some "extreme" slice arguments which should have simply returned an
empty sequence but were raising an IndexError instead.
--
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.
From bugzilla-daemon at portal.open-bio.org Mon Nov 26 23:37:29 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Mon, 26 Nov 2007 18:37:29 -0500
Subject: [Biopython-dev] [Bug 2410] DBSeq & DBSeqRecord should subclass Seq
& SeqRecord
In-Reply-To:
Message-ID: <200711262337.lAQNbTFS014732@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2410
------- Comment #1 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-26 18:37 EST -------
Created an attachment (id=828)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=828&action=view)
Patch to BioSQL/BioSeq.py
This patch does the subclassing I suggested.
The full test suite still passes.
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 27 11:16:25 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 27 Nov 2007 06:16:25 -0500
Subject: [Biopython-dev] [Bug 2405] db_xref and UserWarning: XXX not
recognised as database type: temporarily accepting key
In-Reply-To:
Message-ID: <200711271116.lARBGPMH012776@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2405
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Summary|BioSQL gives UserWarning: |db_xref and UserWarning: XXX
|... not recognised as |not recognised as database
|database type: temporarily |type: temporarily accepting
|accepting key |key
------- Comment #3 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-27 06:16 EST -------
Fixed in CVS by removing the db_xref mapping. This now follows BioPerl and
BioJava usage.
BioSQL/BioSeq.py revision 1.18
BioSQL/Loader.py revision 1.23
BioSQL/__init__.py revision 1.3
Both the BioSQL unit tests still pass.
[Also adding db_xref to the bug title to help anyone searching for this change
in future]
--
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.
From bugzilla-daemon at portal.open-bio.org Tue Nov 27 11:23:47 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Tue, 27 Nov 2007 06:23:47 -0500
Subject: [Biopython-dev] [Bug 2395] Need a commit in BioSQL with MySQL
In-Reply-To:
Message-ID: <200711271123.lARBNl83013085@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2395
biopython-bugzilla at maubp.freeserve.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Comment #5 from biopython-bugzilla at maubp.freeserve.co.uk 2007-11-27 06:23 EST -------
I agree that in a few cases, it might be reasonable to automatically commit
changes (namely server.create_database, db.load records, and perhaps
server.remove_database) but not others (e.g. load_seqrecord).
Deciding everything on a case by case basis is a pain, and for the user it
means they can never be sure one way or the other without checking the
documentation or code.
I'm going to go with "won't fix", and in my defense refer to:
http://www.python.org/dev/peps/pep-0020/
The Zen Of Python, Point #2, "Explicit is better than implicit"
Now I/we need to work on the documentation ;)
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 28 12:24:10 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 28 Nov 2007 07:24:10 -0500
Subject: [Biopython-dev] [Bug 2412] New: NCBIXML. fails parsing with blast
2.2.15 in special cases (Karlin-Altschul)
Message-ID:
http://bugzilla.open-bio.org/show_bug.cgi?id=2412
Summary: NCBIXML. fails parsing with blast 2.2.15 in special
cases (Karlin-Altschul)
Product: Biopython
Version: 1.44
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Main Distribution
AssignedTo: biopython-dev at biopython.org
ReportedBy: bjoern.thorwirth at uni-due.de
this is the blas call i used: blastall -pblastp -dreference.fasta
-i/home/user/workspace/PLGDaemon/src/working_directories/blast_plugin/input2.fasta
-MPAM250 -m7 -e0.01 -gt -G-1 -E-1
XML output is empty.
Here is the Backtrace i got:
(Twisted Stuff)
File
"/home/user/Desktop/biopython/biopython-1.43/build/lib.linux-x86_64-2.4/Bio/Blast/NCBIXML.py",
line 625, in parse
assert len(blast_parser._records) == 0
exceptions.UnboundLocalError: local variable 'blast_parser' referenced before
assignment
(Twisted stuff)
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 28 12:25:48 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 28 Nov 2007 07:25:48 -0500
Subject: [Biopython-dev] [Bug 2412] NCBIXML. fails parsing with blast 2.2.15
in special cases (Karlin-Altschul)
In-Reply-To:
Message-ID: <200711281225.lASCPmY6013832@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2412
------- Comment #1 from bjoern.thorwirth at uni-due.de 2007-11-28 07:25 EST -------
Created an attachment (id=829)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=829&action=view)
Query Fasta
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 28 12:26:31 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 28 Nov 2007 07:26:31 -0500
Subject: [Biopython-dev] [Bug 2412] NCBIXML. fails parsing with blast 2.2.15
in special cases (Karlin-Altschul)
In-Reply-To:
Message-ID: <200711281226.lASCQVNp013895@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2412
------- Comment #2 from bjoern.thorwirth at uni-due.de 2007-11-28 07:26 EST -------
Created an attachment (id=830)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=830&action=view)
reference Fasta File
--
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.
From bugzilla-daemon at portal.open-bio.org Wed Nov 28 12:27:38 2007
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Wed, 28 Nov 2007 07:27:38 -0500
Subject: [Biopython-dev] [Bug 2412] NCBIXML. fails parsing with blast 2.2.15
in special cases (Karlin-Altschul)
In-Reply-To:
Message-ID: <200711281227.lASCRcdl013938@portal.open-bio.org>
http://bugzilla.open-bio.org/show_bug.cgi?id=2412
------- Comment #3 from bjoern.thorwirth at uni-due.de 2007-11-28 07:27 EST -------
Created an attachment (id=831)
--> (http://bugzilla.open-bio.org/attachment.cgi?id=831&action=view)
err out. XML File is empty
--
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.
From mdehoon at c2b2.columbia.edu Thu Nov 29 05:33:51 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Thu, 29 Nov 2007 00:33:51 -0500
Subject: [Biopython-dev] Bio.WWW.ExPASy
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B66C@mail2.exch.c2b2.columbia.edu>
Hi everybody,
The Bio.WWW reorganization has been completed for Bio.WWW.InterPro and
Bio.WWW.SCOP. Now I am looking at Bio.WWW.ExPASy.
Bio.WWW.ExPASy is used to access SwissProt, Prosite, and Prodoc records
through ExPASy. Because of the overlapping functionality in Bio.WWW.ExPASy I
now think it is better to keep this module together as Bio.ExPASy instead of
dividing it into Bio.SwissProt and Bio.Prosite.
Bio.WWW.ExPASy contains six functions:
get_prodoc_entry Interface to the get-prodoc-entry CGI script.
get_prosite_entry Interface to the get-prosite-entry CGI script.
get_prosite_raw Interface to the get-prosite-raw CGI script.
get_sprot_raw Interface to the get-sprot-raw CGI script.
sprot_search_ful Interface to the sprot-search-ful CGI script.
sprot_search_de Interface to the sprot-search-de CGI script.
plus an internally used function _open. (I added the get_prosite_raw function
as it was missing from the existing Bio.WWW.ExPASy).
These functions call the _open function with the appropriate URL.
Inside the _open function, we have the following code:
# Wrap the handle inside an UndoHandle.
uhandle = File.UndoHandle(handle)
# If the key doesn't exist, ExPASy returns nothing.
if not uhandle.peekline():
raise IOError, "no results"
Unfortunately, it is no longer true that ExPASy returns nothing for a
non-existing key. Nowadays, it returns an HTML web page with an error
message. The only exception is the get_prosite_raw function I just added;
here, ExPASy indeed returns nothing for a non-existing key.
So, the uhandle.peekline() will not fail even if the key is non-existing, and
the IOError will not be raised.
In this situation, I think it is better if the functions in Bio.WWW.ExPASy do
not attempt to raise an IOError, and to let the subsequent parsers handle
non-existing queries. The function get_prosite_raw could be an exception,
though I wouldn't be surprised if ExPASy one day decides to make its behavior
consistent with the other functions.
Any comments?
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
From p.j.a.cock at googlemail.com Thu Nov 29 10:48:58 2007
From: p.j.a.cock at googlemail.com (Peter Cock)
Date: Thu, 29 Nov 2007 10:48:58 +0000
Subject: [Biopython-dev] Bio.WWW.ExPASy
In-Reply-To: <6243BAA9F5E0D24DA41B27997D1FD14402B66C@mail2.exch.c2b2.columbia.edu>
References: <6243BAA9F5E0D24DA41B27997D1FD14402B66C@mail2.exch.c2b2.columbia.edu>
Message-ID: <320fb6e00711290248k47363855x38a2fca8e978b323@mail.gmail.com>
> Bio.WWW.ExPASy contains six functions:
>
> get_prodoc_entry Interface to the get-prodoc-entry CGI script.
> get_prosite_entry Interface to the get-prosite-entry CGI script.
> get_prosite_raw Interface to the get-prosite-raw CGI script.
> get_sprot_raw Interface to the get-sprot-raw CGI script.
> sprot_search_ful Interface to the sprot-search-ful CGI script.
> sprot_search_de Interface to the sprot-search-de CGI script.
>
> plus an internally used function _open....
>
> Any comments?
Is it worth adding "download many" functions like the one in GenBank?
If the web API doesn't let us download a list of records by ID, then
we might need some sort of handle wrapper to download them one by one
- that might be too complicated.
Also, regarding handling HTML error pages, you could reuse the simple
code in Bio/WWW/NCBI.py which hunts for certain HTML errors. Or more
simply, try and spot when we get an HTML file instead of plain text?
There is a good case here for a shared "open a URL function" which can
spot HTML error pages.
Peter
From tiagoantao at gmail.com Thu Nov 29 18:25:48 2007
From: tiagoantao at gmail.com (Tiago Antao)
Date: Thu, 29 Nov 2007 18:25:48 +0000 (WET)
Subject: [Biopython-dev] coalescent tutorial text
Message-ID:
Hi,
I am currently writing the tutorial text for the coalescent code.
This text will talk about demography modeling, for which I would like to
include a few images of demographies. For a few examples you can see:
http://popgen.eu/soft/m4s2/list.png
Any opinions about including (more) images in the tutorial? Ideas on
reasonable limits? I was thinking in around half a dozen or so as a
maximum case scenario. Each image would probably occupy 1/10, 1/8 of a
page.
Tiago
From jkhilmer at gmail.com Thu Nov 29 21:50:57 2007
From: jkhilmer at gmail.com (Jonathan Hilmer)
Date: Thu, 29 Nov 2007 14:50:57 -0700
Subject: [Biopython-dev] Numeric dependencies, PDBParser.py
Message-ID: <81277ce10711291350p69341146o37cbdc84031cbdc0@mail.gmail.com>
Sorry if this has been covered before, but I'm new to the list and
haven't found anything searching through the archives.
I'm trying to use BioPython with 2.5 but I see that that PDBParser
requires Numeric. Is there any way to update this dependency besides
running tools to automatically alter code
(numpy.oldnumeric.alter_code1)?
I tried going through and changing 'Numeric import Float0' to 'numpy
import float' (in several \PDB\ files) until I found another Numeric
import of 'matrixmultiply'. Rather than continue on this path and
possibly break things (I'm a programming novice) I'm hoping someone
has an easier solution.
Thanks,
Jonathan
From mdehoon at c2b2.columbia.edu Fri Nov 30 04:00:24 2007
From: mdehoon at c2b2.columbia.edu (Michiel De Hoon)
Date: Thu, 29 Nov 2007 23:00:24 -0500
Subject: [Biopython-dev] Bio.WWW.ExPASy
References: <6243BAA9F5E0D24DA41B27997D1FD14402B66C@mail2.exch.c2b2.columbia.edu>
<320fb6e00711290248k47363855x38a2fca8e978b323@mail.gmail.com>
Message-ID: <6243BAA9F5E0D24DA41B27997D1FD14402B66D@mail2.exch.c2b2.columbia.edu>
> > Bio.WWW.ExPASy contains six functions:
> >
> > get_prodoc_entry Interface to the get-prodoc-entry CGI script.
> > get_prosite_entry Interface to the get-prosite-entry CGI script.
> > get_prosite_raw Interface to the get-prosite-raw CGI script.
> > get_sprot_raw Interface to the get-sprot-raw CGI script.
> > sprot_search_ful Interface to the sprot-search-ful CGI script.
> > sprot_search_de Interface to the sprot-search-de CGI script.
> >
> > plus an internally used function _open....
> >
> > Any comments?
>
> Is it worth adding "download many" functions like the one in GenBank?
> If the web API doesn't let us download a list of records by ID, then
> we might need some sort of handle wrapper to download them one by one
> - that might be too complicated.
For now, I'd like to focus just on the existing functions.
> Also, regarding handling HTML error pages, you could reuse the simple
> code in Bio/WWW/NCBI.py which hunts for certain HTML errors. Or more
> simply, try and spot when we get an HTML file instead of plain text?
> There is a good case here for a shared "open a URL function" which can
> spot HTML error pages.
Some of the functions in Bio.WWW.ExPASy return the records as a HTML page, so
just checking if the returned file is HTML or not won't suffice to find
non-existing keys. See the following table, showing the format of the record
/ the format of errors:
get_prodoc_entry HTML/HTML
get_prosite_entry HTML/HTML
get_prosite_raw Raw/Nothing
get_sprot_raw Raw/HTML
sprot_search_ful HTML/HTML
sprot_search_de HTML/HTML
Now, there are _extract_record functions in Bio.Prosite and
Bio.Prosite.Prodoc that take the output from get_prodoc_entry,
get_prosite_entry and fish out the record from the HTML. One possibility
would be to let the _extract_record function check for HTML error pages; this
function raises "ValueError: No data found in web page." if no data is found
in the HTML. But, if we call the appropriate _extract_record from
get_prodoc_entry, get_prosite_entry, then these two functions become very
close to what is already in Bio.Prosite.ExPASyDictionary and
Bio.Prosite.Prodoc.ExPASyDictionary. The ExPASyDictionaries use
get_prodoc_entry, get_prosite_entry to access ExPASy, and then extract the
record. So, if we call _extract_record inside get_prodoc_entry,
get_prosite_entry, then Bio.WWW.ExPASy.get_prodoc_entry(key) is virtually the
same as Bio.Prosite.Prodoc.ExPASyDictionary[key], and the same for Prosite.
So I think we have two options:
1) Bio.ExPASy contains the low-level functions to access ExPASy. No error
checking whatsoever; the calling function is responsible for making sure
that there is actually a record contained in the results.
Bio.Prosite.ExPASyDictionary, Bio.Prosite.Prodoc.ExPASyDictionary,
Bio.SwissProt.Sprot.ExPASyDictionary contain the high-level functions to
access ExPASy, which do the error checking and extract the record from the
HTML.
2) Make the only high-level functions available, to make sure the error
checking is always done.
My preference is 1).
--Michiel.
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032
Peter
From biopython at maubp.freeserve.co.uk Fri Nov 30 15:19:46 2007
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Fri, 30 Nov 2007 15:19:46 +0000
Subject: [Biopython-dev] Numeric dependencies, PDBParser.py
In-Reply-To: <81277ce10711291350p69341146o37cbdc84031cbdc0@mail.gmail.com>
References: <81277ce10711291350p69341146o37cbdc84031cbdc0@mail.gmail.com>
Message-ID: <320fb6e00711300719mf2dd7cbt62061b9be80df99b@mail.gmail.com>
On Nov 29, 2007 9:50 PM, Jonathan Hilmer wrote:
> Sorry if this has been covered before, but I'm new to the list and
> haven't found anything searching through the archives.
>
> I'm trying to use BioPython with 2.5 but I see that that PDBParser
> requires Numeric.
Is there a problem installing Numeric? There is nothing to prevent you having
both Numeric and NumPy installed on the same machine.
> Is there any way to update this dependency besides
> running tools to automatically alter code
> (numpy.oldnumeric.alter_code1)?
Because Biopython also has some C code, moving the project as a whole
from Numeric to NumPy is non-trivial. You could try the patch on Bug 2251,
http://bugzilla.open-bio.org/show_bug.cgi?id=2251
Peter