On Thu, Mar 12, 2009 at 03:36:22PM -0700, Christopher Lee wrote: -> Hi Titus, -> seqInfoDict's values should be objects with attributes. The Pygr -> Developer's Guide gives a little background on what seqInfoDict is for: -> "seqInfoDict: a dictionary-like object that for each valid sequence ID -> returns an object with attributes providing information about that -> sequence. This allows you, if you wish, to implement an efficient -> mechanism for retrieving information about a sequence that does not -> need to retrieve the sequence string itself." -> I will update this description to say exactly what attributes a -> seqInfoDict value object must have: the only one that is needed -> currently is "length", which just gives the sequence length. I -> believe this attribute is used only by NLMSA, so far.
OK, thanks! So then let me ask a slightly leading question: how can I check to see if a new seqdb implementation is "correct", i.e. has all the necessary components for pygr to load, pickle, use in an NLMSA, etc? Is the best way to simply try doing all of that? In which case, what additional operations are there to cover? -> > class MemSequence(SequenceBase): -> > def _init_subclass(cls, db, **kwargs): -> > cls.db = db -> > db.seqInfoDict = kwargs['theDict'] -> > _init_subclass = classmethod(_init_subclass) -> -> wouldn't it be clearer to make seqInfoDict an explicit named argument? -> -> class MemSequence(SequenceBase): -> def _init_subclass(cls, db, seqInfoDict, **kwargs): -> [...] Hmm, OK, but I'm not sure how that argument gets passed through. I'll have to try it out. -> The SequenceDB model assumes that there is some back-end that stores -> the sequences, so when the user requests a sequence by ID, SequenceDB -> will automatically construct sequence objects (using the itemClass) -> that should initialize themselves from that back-end storage. Right. -> Your MemSequence is using seqInfoDict as that back-end (for the -> moment, anyway), which is fine. However, the values in the -> seqInfoDict are supposed to be objects with named attributes, -> including at least "length" (NLMSA requires this from any sequence DB -> it works with). So you could do something like this: [ ... ] gotcha. [ ... ] -> > So, my next step is to provide a simple dict-like interface to Alexs -> > code that can then replace 'd'. Anything else I need to note in order -> > to proceed with linking this to an actual on-disk file of sequences? -> -> Since your back-end storage will just be a file, I think you should -> just subclass from our SequenceFileDB (instead of SequenceDB). The -> only thing that SequenceFileDB adds is proper support for a "filepath" -> argument (including pickling). In fact, if you don't need to add -> extra pickle attributes, you won't need to subclass it at all. Just -> use it as-is, passing it your itemClass as an argument to the -> constructor. Hmm. I'll try that and get back to you... cheers, --titus -- C. Titus Brown, [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
