On Wed, Mar 18, 2009 at 01:43:14PM -0700, Christopher Lee wrote:
->
-> On Mar 18, 2009, at 12:34 PM, C. Titus Brown wrote:
-> > I don't think
-> >
-> > class SomeClass(...):
-> > __invert__ = classutil.standard_invert
-> > ...
-> > _inverseClass = FooBar
-> >
-> > is an obvious construct, although I do understand why you defined
-> > things
-> > that way. How about,
-> >
-> > __invert__ = classutil.lazy_create(FooBar)
-> >
-> > instead, for example? Then FooBar would be obviously and directly
-> > connected to __invert__.
->
-> OK, I see how this is clearer in a single line than setting __invert__
-> and _inverseClass in two consecutive lines in my original code. Your
-> lazy_create() would return a callable function that behaves like my
-> existing standard_invert. Do you want to implement this, or should I?
done; now you can do
__invert__ = classutil.lazy_create_invert(_SequenceDBInverse)
in a class definition to get a one-time-only lazily created __invert__
object per parent class. This object is saved in self._inverseObj.
I could have made the function entirely generic, e.g.
__invert__ = classutil.lazy_create(_SequenceDBInverse)
and stored the created object in an isolated and unreachable scope, but
then the object would have been inaccessible for debugging purposes,
too. If it is (or ends up being) a frequent pattern we might want to do
this anyway, but I thought it was a poor tradeoff for now.
Note, I didn't remove standard_invert from throughout the codebase, only
from within seqdb.py. We can change it elsewhere as we do code reviews.
cheers,
--titus
--
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
-~----------~----~----~----~------~----~------~--~---
