[pygr-notify] Issue 56 in pygr: unable to access the sequence object via a saved bound schema attribute :(

[codesite-noreply at google.com]

Updates:
	Status: Invalid
	Cc: ti... at idyll.org

Comment #1 on issue 56 by cjlee112: unable to access the sequence object  
via a saved bound schema attribute :(
http://code.google.com/p/pygr/issues/detail?id=56

I'm not able to reproduce this problem.  Here's what I tried: I combined  
all the
initial setup steps listed in this report into a single file, issue56.py  
(attached),
which saves the relevant ensembl table & annotation info into pygr.Data.  I  
then
followed the steps to reproduce the bug, but didn't encounter the reported  
problem:

>>> import pygr.Data
>>> transcriptDB =  
pygr.Data.Bio.Annotation.Ensembl.homo_sapiens_core_47_36i.transcript()
>>> transcript = transcriptDB[1]
>>> exons = transcript.exons
>>> for e in exons: print e.id, e.seq_region_start
...
1 19397
2 14600
3 8131
4 7778
5 7465
6 7096
7 6721
8 6611
9 6470
10 5767
11 5659
12 4863
13 4274
>>> for e in exons: print e.id, len(e.sequence)
...
1 272
2 154
3 98
4 146
5 140
6 131
7 197
8 17
9 138
10 43
11 105
12 38
13 91
>>> for e in exons: print e.id, str(e.sequence)
...
1
GGAAAGCGGGTCAAGGCGTAGGGCTGGAGGGCAGGGGCGGGCCCTGGGCGTGGGCTGGGGGTCCTGCCCCGGGGCGCACCCCGGGCGAGGGCTGCCCGGAGGAGCCGAGGTTGGCGGACAGCTTGGCCCTGAGCTTGAGGGGAAGGCAGCGATGGGACAAAGGACGGAGGTCTAGGAAGAGGGTCTGCAGAGCAGAAAGCACGGGTAGGGGCGGCCTGACGCTCGGAAGACAACGCATGGGAGCCGTGTGCACGTCGGGAGCTCGGAGTGAG
2
GCACCATGACTCCTGTGAGGATGCAGCACTCCCTGGCAGGTCAGACCTATGCCGTGCCCTTCATCCAGCCAGACCTGCGGCGAGAGGAGGCCGTCCAGCAGATGGCGGATGCCCTGCAGTACCTGCAGAAGGTCTCTGGAGACATCTTCAGCAG
3
GTAGAGCAGAGCCGGAGCCAGGTGCAGGCCATTGGAGAGAAGGTCTCCTTGGCCCAGGCCAAGATTGAGAAGATCAAGGGCAGCAAGAAGGCCATCAA
4
GTGTTCTCCAGTGCCAAGTACCCTGCTCCAGGGCGCCTGCAGGAATATGGCTCCATCTTCACGGGCGCCCAGGACCCTGGCCTGCAGAGACGCCCCCGCCACAGGATCCAGAGCAAGCACCGCCCCCTGGACGAGCGGGCCCTGCA
5
GAGAAGCTGAAGGACTTTCCTGTGTGCGTGAGCACCAAGCCGGAGCCCGAGGACGATGCAGAAGAGGGACTTGGGGGTCTTCCCAGCAACATCAGCTCTGTCAGCTCCTTGCTGCTCTTCAACACCACCGAGAACCTGTA
6
AAGAAGTATGTCTTCCTGGACCCCCTGGCTGGTGCTGTAACAAAGACCCATGTGATGCTGGGGGCAGAGACAGAGGAGAAGCTGTTTGATGCCCCCTTGTCCATCAGCAAGAGAGAGCAGCTGGAACAGCA
7
GTCCCAGAGAACTACTTCTATGTGCCAGACCTGGGCCAGGTGCCTGAGATTGATGTTCCATCCTACCTGCCTGACCTGCCCGGCATTGCCAACGACCTCATGTACATTGCCGACCTGGGCCCCGGCATTGCCCCCTCTGCCCCTGGCACCATTCCAGAACTGCCCACCTTCCACACTGAGGTAGCCGAGCCTCTCAA
8 ACCTACAAGATGGGGTa
9
acaccacccccaccgcccccaccaccacccccaGCTCCTGAGGTGCTGGCCAGTGCACCCCCACTCCCACCCTCAACCGCGGCCCCTGTAGGCCAAGGCGCCAGGCAGGACGACAGCAGCAGCAGCGCGTCTCCTTCA
10 TCCAGGGAGCTCCCAGGGAAGTGGTTGACCCCTCCGGTGGCTG
11
ACTCTGCTAGAGTCCATCCGCCAAGCTGGGGGCATCGGCAAGGCCAAGCTGCGCAGCATGAAGGAGCGAAAGCTGGAGAAGCAGCAGCAGAAGGAGCAGGAGCAA
12 TGAGAGCCACGAGCCAAGGTGGGCACTTGATGTCGGAT
13
TGCTCCATGGGGGGACGGCTCCACCCAGCCTGCGCCACTGTGTTCTTAAGAGGCTTCCAGAGAAAACGGCACACCAATCAATAAAGAACTG
>>> e.__class__
<class 'pygr.classutil.AnnotationSeq_exon'>

One possible difference vs. Jenny's test environment is that I am using my  
original
ensembl/seqregion.py module.  I also tested using her September pyensembl  
package's
seqregion.py, and got the same result.  I don't see how differences in this  
file
could affect this test result anyway.  But it would probably be a good idea  
if Jenny
could test the same setup (i.e. rm .pygr_data to ensure you're starting  
with a clean
slate; run issue56.py to create entries in .pygr_data; run the steps above  
to test
e.sequence), using her latest pyensembl seqregion.py or whatever pyensembl  
version
she was using when she originally encountered the problem.  And of course,  
please
first get the latest pygr code from the git repository.

I did encounter (and fix) one subtle schema problem.  Titus added code to
AnnotationDB.__init__ that tries to load one annotation, just to make sure  
that the
user has defined all the database connections correctly (commit ID fe22781).
However, this caused a very subtle problem: this loaded a single object  
(with key
value 1) into the cache, PRIOR to pygr.Data.ResourceFinder.applySchema()  
changing the
itemClass to accept schema bindings (like the "exons" attribute).   
Therefore this one
object lacks the "exons" attribute.  It just so happened that Jenny also  
chose
transcript[1] as her example, so that this key (and only this key) would  
fail to have
the "exons" attribute.  I fixed the problem by changing Titus' code to NOT  
cache
anything as a side-effect of its check.

Attachments:
	issue56.py  3.3 KB

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings