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