On Thu, May 28, 2009 at 06:25:41AM -0700, Istvan Albert wrote:
-> > After discussion I'll provide patches or enter these into the issue
-> > tracker (or not, based on the discussion).
->
-> I think anything that simplifies the usage is welcome. I would even
-> start with renaming the whole thing
->
-> cnestedlist.NLMSA?
[ ... ]
-> AlignmentStorage
Let's wait until after 0.8 to discuss. AlignmentMapping is what I'd
come up with for myself.
-> > I think we should either define an __iter__ function that says "don't do
-> > this!" *or* we should support the full range of dict functions on NLMSA.
-> > I vote for the former for 0.8, and the latter for post-0.8.
->
-> I think some of the original dict functions were ill conceived, that's
-> why you end up with both items() and iteritems(), so going for a full
-> support may mean a lot of work to implement features that are not all
-> the useful. Picking the main use cases like iteration may be enough.
We've already done it for the seqdb and annotation db stuff; it's not
much work. (It's annoying and detail-oriented, though.)
I'll take this as a vote for putting in an __iter__ function that
complains, for now ;)
-> > Third, NLMSASlice objects could use a more informative __repr__. ?How
-> > about including the sequence ID (slice.seq.id) in there?
->
-> Here I probably have opinion may differ from yours. I think it is a
-> mistake to try be too helpful. I found that when a class does not
-> print its class name but some "helpful" information, I end up with
-> more work. That is because most of the time one does not know how to
-> use the class, and wants to look up that info in the docs. So I am
-> usually more happy with <ClassName instance> type of default reprs
-> that point me where to look.
So, how about
<ClassName instance (sequence %s)>
? Fits both our concerns...
-> I remember clearly a year or two ago that when I first tried your
-> example on yeast you showed python prompt examples, I wrote the same
-> thing as a script ... but it turns out one of the classes raises an
-> exception if you invoke str on it (with print) rather then repr (the
-> python prompt invokes that). I was so stupefied by this error that I
-> gave up and moved on, I thought the library must be buggy. I revisited
-> the example maybe a year later when I needed something similar. So I
-> would not misunderestimate the complexities that can arise from
-> __repr__ vs __str__ and it is much better to stick to defaults.
heh, ok.
-> > And, finally, NLMSASlice keys(), values(), and edges() all take a large
-> > (and identical) set of parameters. ?It might be nice to set these
-> > parameters *once* for a given NLMSA instance, and then have those
-> > default settings apply for future queries:
->
-> +1
->
-> > Hmm, perhaps one way to do this would be to provide an NLMSA wrapper
-> > object:
-> >
-> > ? al = cnestedlist.NLMSA(...)
-> > ? wrap = NLMSAParamWrapper(al, mingaps=4)
-> > ? slice = wrap[seq].keys() ? # => mingaps=4 automatically used in keys()
->
-> -1 ... another class is another headache, wrapper classes should be
-> build by the users themselves, those that feel that they need them.
Providing support (e.g. a base class, or NLMSA behavior) for said
wrapper classes would be nice, IMO.
I don't think there's a problem providing "advanced" functionality in
the pygr lib as long as it's not an additional burden on understanding.
cheers,
--t
--
C. Titus Brown, c...@msu.edu
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pygr-dev" group.
To post to this group, send email to pygr-dev@googlegroups.com
To unsubscribe from this group, send email to
pygr-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pygr-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
