Ken Tilton <[EMAIL PROTECTED]> writes: > > if any concepts have survived to the Python version. Since Python's object > > model is sufficiently different, the system is based on rules being > > defined per-class... > > That will be a total disaster for PyCells, if true. But I do not think it > is. You just need a constructor that takes some slot initializers, and > initialize the slots to one of: a normal value; an InputCell itself > initialized with a starting value, if only nil; or a RuledCell itself > initialized with a lambda.
Hmm, just tried it: >>> class A(cells.cellular): ... def __init__(self): ... self.a = cells.InputCell(10) ... self.b = cells.RuleCell(lambda self: self.a+1, self, None) >>> a = A() >>> a.a 10 >>> a.b 11 So it does work out-of-the-box ;-) > PyCells looks like it will be a project for SoC2006, so you may as well > relax. You really want to start a SoC project on something that takes about two weeks from an average Python programmer? What does the guy do for the rest of the summer? (I think I spent 4-5 hours on this actually sitting on the computer, sandwiched between remodeling and cleaning and work. The rest of the two weeks would be making it more robust ;-) > > Features: > > - Tracks changes to input cells dynamically (normal attributes are not > > tracked) > > Ha! All your rules depend on the input cell itself! How about A depends on > B depends on C? :) Oops. I'm sorry for the inaccurate terminology. They depend only the cells they use as inputs (their "children"), and not only on InputCells. (I use the parent-child terminology because as English is not my native language, I had trouble remembering which depend* variable was which ;-) > Quite hard to test deliberately, but it happens "in nature". But it will > not happen until you do A->B->C. Once you have /that/ working, make A the > input, then have B and C both use A. But also have B use C, and jiggle > things around until A happens to think it should update B first, then C. > What happens is that B runs and uses C, but C has not been updated yet. C > is inconsistent with A, but is being used to calculate a new value for B > which does see the new value of A. Mismatch! B will get sorted out in a > moment when C gets recalculated and tells B to calculate a second time, > but meanwhile after the first recalculation of B the on-change callback > for that got invoked, missiles were launched, and Moscow has been > destroyed. If you check the testcase, you'll see there are such dependencies, and all the callbacks fire just once (and in dependency-related order). Furthermore, the timestamp mechanism SHOULD take care of those (if the cell is older than its children, it gets recalculated before it will provide any data, and thus C will get recalculated before B uses it. > ps. In the getattr for any Cell-mediated slot, look to see if "parent" is > non-nil. If so, set up a dependency. k Already done, see BaseCell.value() ;-) -- Lasse Rasinen [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
