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

[Alex Martelli]

Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
   ...
> > an extension that allows the programmer to specify how the value of
> > some slot (Lisp lingo for "member variable") can be computed.  It
> > frees the programmer from having to recompute slot values since Cells
   ...
> I have not looked at Cells at all, but what you are saying here sounds
> amazingly like Python's properties to me. You specify a function that
> calculates the value of an attribute (Python lingo for something like a

You're right that the above-quoted snipped does sound exactly like
Python's properties, but I suspect that's partly because it's a very
concise summary.  A property, as such, recomputes the value each and
every time, whether the computation is necessary or not; in other words,
it performs no automatic caching/memoizing.

A more interesting project might therefore be a custom descriptor, one
that's property-like but also deals with "caching wherever that's
possible". This adds interesting layers of complexity, some of them not
too hard (auto-detecting dependencies by introspection), others really
challenging (reliably determining what attributes have changed since
last recomputation of a property).  Intuition tells me that the latter
problem is equivalent to the Halting Problem -- if somewhere I "see" a
call to self.foo.zap(), even if I can reliably determine the leafmost
type of self.foo, I'm still left with the issue of analyzing the code
for method zap to find out if it changes self.foo on this occasion, or
not -- there being no constraint on that code, this may be too hard.

The practical problem of detecting alterations may be softened by
realizing that some false positives are probably OK -- if I know that
self.foo.zap() *MAY* alter self.foo, I might make my life simpler by
assuming that it *HAS* altered it. This will cause some recomputations
of property-like descriptors' values that might theoretically have been
avoided, "ah well", not a killer issue.  Perhaps a more constructive
approach would be: start by assuming the pseudoproperty always
recomputes, like a real property would; then move toward avoiding SOME
needless recomputations when you can PROVE they're needless. You'll
never avoid ALL needless recomputations, but if you avoid enough of them
to pay for the needed introspection and analysis, it may still be a win.
As to whether it's enough of a real-world win to warrant the project, I
pass -- in a research setting it would surely be a worthwhile study, in
a production setting there are other optimizations that look like
lower-hanging fruits to me.  But, I'm sure the Cells people will be back
with further illustrations of the power of their approach, beyond mere
"properties with _some_ automatic-caching abilities".


Alex