On May 27, 11:55 pm, "C. Titus Brown" <c...@msu.edu> 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?

That's like having a car where the fenders are missing, things that
should be covered are showing. Also I don't even know how to pronounce
this, and I think for those verbalize thoughts in minds this is no
small obstacle, here is a name:

AlignmentStorage

> 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.

> Second, NLMSASlice objects don't behave like a full mapping object,
> either.  I think that's OK for now but we should fix this, post-0.8.

Again naming. I think a name should be chosen such at to have some
meaning. For those who use these a lot they become second nature, and
thus it is hard to remember what it looks like when you see names that
intuitively make little sense to you.

> 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.

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.

> 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.

Istvan
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to