PyCells and peak.events
by Kevin Dangoor
When Phillip Eby works on something that has “head-exploding” properties, it’s worth paying attention to see why he’s putting forth the effort: PyCells and peak.events. Sometimes these things look academic and not useful in reality, and I’ve seen responses along these lines to TurboGears’ use of Rule Dispatch. Really, though, this looks quite valuable for certain kinds of problems in certain kinds of systems.
I’m a big fan of your project TurboGears because it’s written in Python and I strongly prefer a framework written in a language I already use, as opposed to learning Ruby to use Ruby on Rails.
The one thing that holds me back, however, is your use of SQLObject. People say it’s going to improve, but given your modular model, shouldn’t you choose best of breed right now? What is the status of SQLAlchemy within the TurboGears project, and would you consider swapping out SQLObject for SQLAlchemy?
In any case, keep up the good work.
[...] First Time Here? « PyCells and peak.events [...]
Well, the PyCells stuff *is* academic for now, unless OSAF wants me to look into it more for Chandler. It’s also literally academic, being a Summer of Code student project.
In the meantime, I’ve been working on the successor to RuleDispatch and PyProtocols: peak.rules.
See http://www.eby-sarna.com/pipermail/peak/2006-May/002535.html and http://www.eby-sarna.com/pipermail/peak/2006-May/002547.html for more info.
>>
This sounds an awful lot like the following:
http://www.rebelscience.org/Cosas/Reliability.htm
Do you think they are on to something (the rebelscience folk)?
The good news, though, is that the Common Lisp Cells (which the PyCells project is porting) is almost ten years old and has been used to wire many a GUI framework (Mac OS9, win32, Gtk, Tk, and one sitting atop OpenGL/Freeglut) and was used in a rather large enterprise application, for everything from the GUI (this was the win32 GUI) and even to animate the object database.
Nothing academic there, and I would note also that Cells was developed in blithe ignorance of the substantial prior and existing art, purely as a reaction to specific application engineering problems. I think that is one reason it has been successful in real-world use where classic constraint programming has not.