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

Bill Atkins NOatkinwSPAM at rpi.edu
Sun May 7 04:53:20 EDT 2006


"Serge Orlov" <Serge.Orlov at gmail.com> writes:

> Bill Atkins wrote:
>> "Serge Orlov" <Serge.Orlov at gmail.com> writes:
>>
>> > Ken Tilton wrote:
>> >> It is vastly more disappointing that an alleged tech genius would sniff
>> >> at the chance to take undeserved credit for PyCells, something probably
>> >> better than a similar project on which Adobe (your superiors at
>> >> software, right?) has bet the ranch. This is the Grail, dude, Brooks's
>> >> long lost Silver Bullet. And you want to pass?????
>> >>
>> >> C'mon, Alex, I just want you as co-mentor for your star quality. Of
>> >> course you won't have to do a thing, just identify for me a True Python
>> >> Geek and she and I will take it from there.
>> >>
>> >> Here's the link in case you lost it:
>> >>
>> >>      http://www.lispnyc.org/wiki.clp?page=PyCells
>> >>
>> >> :)
>> >>
>> >> peace, kenny
>> >>
>> >> ps. flaming aside, PyCells really would be amazingly good for Python.
>> >> And so Google. (Now your job is on the line. <g>) k
>> >
>> > Perhaps I'm missing something but what's the big deal about PyCells?
>> > Here is 22-lines barebones implementation of spreadsheet in Python,
>> > later I create 2 cells "a" and "b", "b" depends on a and evaluate all
>> > the cells. The output is
>> >
>> > a = negate(sin(pi/2)+one) = -2.0
>> > b = negate(a)*10 = 20.0
>> >
>> > =================== spreadsheet.py ==================
>> > class Spreadsheet(dict):
>> >     def __init__(self, **kwd):
>> >         self.namespace = kwd
>> >     def __getitem__(self, cell_name):
>> >         item = self.namespace[cell_name]
>> >         if hasattr(item, "formula"):
>> >             return item()
>> >         return item
>> >     def evaluate(self, formula):
>> >         return eval(formula, self)
>> >     def cell(self, cell_name, formula):
>> >         "Create a cell defined by formula"
>> >         def evaluate_cell():
>> >             return self.evaluate(formula)
>> >         evaluate_cell.formula = formula
>> >         self.namespace[cell_name] = evaluate_cell
>> >     def cells(self):
>> >         "Yield all cells of the spreadsheet along with current values
>> > and formulas"
>> >         for cell_name, value in self.namespace.items():
>> >             if not hasattr(value, "formula"):
>> >                 continue
>> >             yield cell_name, self[cell_name], value.formula
>> >
>> > import math
>> > def negate(x):
>> >     return -x
>> > sheet1 = Spreadsheet(one=1, sin=math.sin, pi=math.pi, negate=negate)
>> > sheet1.cell("a", "negate(sin(pi/2)+one)")
>> > sheet1.cell("b", "negate(a)*10")
>> > for name, value, formula in sheet1.cells():
>> >     print name, "=", formula, "=", value
>> >
>>
>> I hope Ken doesn't mind me answering for him, but Cells is not a
>> spreadsheet (where did you get that idea?).
>
> It's written on the page linked above, second sentence: "Think of the
> slots as cells in a spreadsheet, and you've got the right idea". I'm
> not claiming that my code is full PyCell implementation.

Unfortunately, it's *nothing* like a full PyCell implementation.  I
explained what Cells is above.  It is not merely a spreadsheet - it is
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
can transparently update them.  It has to do with extending the object
system, not with merely setting tables in a hash and then retrieving
them.

>> It does apply the basic
>> idea of a spreadsheet to software - that is, instead of updating value
>> when some event occurs, you specify in advance how that value can be
>> computed and then you stop worrying about keeping it updated.
>
> The result is the same. Of course, I don't track dependances in such a
> tiny barebones example. But when you retrieve a cell you will get the
> same value as with dependances. Adding dependances is left as an
> exercise.
>
>>
>> Incidentally, is this supposed to be an example of Python's supposed
>> "aesthetic pleasantness"?
>
> Nope. This is an example that you don't need macros and
> multi-statements. Ken writes: "While the absence of macros and
> multi-statement lambda in Python will make coding more cumbersome". I'd
> like to see Python code doing the same if the language had macros and
> multi-statement lambda. Will it be more simple? More expressive?

FWIW (absolutely nothing, I imagine), here is my take on your
spreadsheet:

  http://paste.lisp.org/display/19766

It is longer, for sure, but it does more and I haven't made any
attempt to stick to some minimum number of lines.

>> I find it a little hideous, even giving you
>> the benefit of the doubt and pretending there are newlines between
>> each function.  There's nothing like a word wrapped in pairs of
>> underscores to totally ruin an aesthetic experience.
>
> I don't think anyone who is not a master of a language can judge
> readability. You're just distracted by insignificant details, they
> don't matter if you code in that language for many years. I'm not going
> to tell you how Lisp Cell code looks to me ;)
>
>> P.S. Is this really a spreadsheet?  It looks like it's a flat
>> hashtable...
>
> Does it matter if it's flat or 2D?
>

Not really, because this is not Cells.

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan



More information about the Python-list mailing list