A critic of Guido's blog on Python's lambda
lrasinen at iki.fi
Mon May 15 07:10:25 CEST 2006
Ken Tilton <kentilton at gmail.com> 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()
So it does work out-of-the-box ;-)
> PyCells looks like it will be a project for SoC2006, so you may as well
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
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() ;-)
lrasinen at iki.fi
More information about the Python-list