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

[Ken Tilton]

Lasse Rasinen wrote:
> Ken Tilton <kentilton at gmail.com> writes:
> 
> 
>>ps. flaming aside, PyCells really would be amazingly good for Python. And
>>so Google. (Now your job is on the line. <g>) k
> 
> 
> Here's something I wrote this week, mostly as a mental exercise ;-)

It's fun, right? But what you have is a complete wreck. :)

> The whole code is available at <http://www.iki.fi/~lrasinen/cells.py>,
> I'll include a test example below. Feel free to flame away ;-)
> 
> (As for background: I like CL better as a language, but I also like Python
> a lot. However, I was employed for 3 years as a developer and maintainer
> in a Python data mining application, so I'm more fluent in Python than CL.)
> 
> The code is mostly based on Kenny's descriptions of Cells in the following
> messages:
> <0mp7g.600$4q2.70 at fe12.lga>
> <NUP7g.17$G22.12 at fe11.lga>
> <xcn8g.11$FO5.5 at fe08.lga>
> 
> In addition, I have looked at the CL source code briefly, but I'm not sure
> 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.

Trust me, you lose a vast amount of power unless different instances of 
the same class can have different rules for the same slot.

>... (however, if you define a rule by hand in the __init__
> function, it'll work also. I think; haven't tested).
> 
> I can possibly be persuaded to fix bugs in the code and/or to implement
> new features ;-)

PyCells looks like it will be a project for SoC2006, so you may as well 
relax. But I understand if you want to keep going, it is great fun. btw, 
I have met more than a few people who had done something like Cells 
independently, and there are many full-blown similar implementations 
around. Mine is just the best. <g> Kidding, i do not really know, there 
are so many.

> 
> 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? :)

> - Callbacks for changes (see caveats)
> - Requires Python 2.4 for the decorator syntax (@stuff)
> - Should calculate a cell only once per change (haven't tested ;-)

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.

> 
> Caveats:
> - The input cell callbacks are not called with the class instance 
>   as the first argument, while the rule cell callback are. This
>   is mostly due to laziness.

And unacceptable!

have fun. :)

kenny

ps. In the getattr for any Cell-mediated slot, look to see if "parent" 
is non-nil. If so, set up a dependency. k

-- 
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
    Attorney for Mary Winkler, confessed killer of her
    minister husband, when asked if the couple had
    marital problems.