A critic of Guido's blog on Python's lambda

[Lasse Rasinen]

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()
>>> 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
lrasinen at iki.fi