Lasse Rasinen wrote: > Ken Tilton <[EMAIL PROTECTED]> 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: > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > > 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. -- http://mail.python.org/mailman/listinfo/python-list
