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

[Lasse Rasinen]

[I trimmed some of the newsgroups away; this mostly concerns Python and Lisp]

Ken Tilton <kentilton at gmail.com> writes:

> Lasse Rasinen wrote:
> > 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:
> >
> > [snip example]
> >
> > So it does work out-of-the-box ;-)
> 
> So why exactly did you say that the differences in the object model made
> it impossible? I was really stunned by that claim. And you sounded so
> confident. What went wrong there? It was trivial, right? How did you miss
> that?

Simple: I didn't think to try that before you asked.

I did not say the differences in the object model made it impossible, I
said the system is based on rules defined per-class. My goal was to
explore the how one would go about defining data flow in Python, which is
why I concentrated on class-level definitions first.

The situation is similar to functions in classes. Normally you'd define
them like this:

class X:
  def function(self, ...):
    ...

However, you can just as well set them, even on per instance basis:
x = X()
x.another_function = lambda self, x: return x+2


I also think(*) that while one would have the option to define
per-instance rules, in a Python implementation one would structure the
code so that common rules would be class-related, and the per-instance
rules would be used less frequently, used only when you absolutely need
them.

(*) Unfounded Gut Feeling(TM); if your project is successful, we can
revisit this prediction in September ;-) 

> >>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 ...
> 
> You sound so confident. :)

Indeed. Having reread the post I do think the tone was possibly a tad
arrogant. However:

> A new test suite, documentation (a first, there is none now), a full port
> of Cells in all their ten years of sophisticated evolution and variety
> (no, not your stupid pet trick), and as a demo project an entire
> cells-driven GUI, probably a port of my new Celtk (+ Cells Tk) work, all
> in a language without macros, without special variables, with a more
> modest OO system, and limited first class functions... oh, I think we'll
> keep him busy. :)

I did not know all this. The list above does sound like a full summer of
work ;)

I assumed that PyCells referred to the core dependency tracking module
which (even now) does not sound like a such huge task, especially when one
has the reference implementation ;-)

As I said above, I was mostly concerned with exploring how the data flow
system would work, so I haven't implemented the various different types of
cells in Cells. So there would obviously be a bit more work if one is
implementing all that, but still, two caffeine and youth powered student
weeks can achieve a lot ;-)

What "your stupid pet trick" would be referring to? The use of the
__getattribute__ method (which is quite close to SLOT-VALUE-USING-CLASS),
or the use of @decorator syntax to reduce typing and redundancy?

> Now since you are such a genius, maybe you can help with something. Trust
> me on this: this is one place where macros would be able to hide a ton of
> implementation wiring it does no one any good to look at, and actually
> turns into a maintenance nightmare whenever Cells might get revised.

I'd probably use decorators a lot, since they let you play around with
function objects. If they are suitably chosen and designed, the interface
should stay pretty stable even while the wiring is changed.

(Decorator background:

The regular python Python function definition would be
as follows:

def foo(x,y,z):
  ...

would be in CL (if CL were Lisp-1 with symbol-function-or-value) more or less:

(setf (symbol-function-or-value 'foo) (lambda (x y z) ...)

The decorated syntax would be:

@magic_decorator
def foo(x,y,z):
  ...

and the translation:
(setf (symbol-function-or-value 'foo)
 (funcall magic-decorator #'(lambda (x y z)
  ...)))
)
-- 
Lasse Rasinen
lrasinen at iki.fi