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

Lasse Rasinen lrasinen at iki.fi
Tue May 16 13:12:10 EDT 2006


Ken Tilton <kentilton at gmail.com> writes:

> If you want to insist on how perfect your code is, please go find
> ltktest-cells-inside.lisp in the source you downloaded and read the long
> comment detailing the requirements I have identified for "data integrity".
> Then (a) tell me how your code fails at integrity, (b) fix it, and (c)
> tell me again how easy Cells is. :)

Found it and read it; it was most enlightening. I claim my system fulfills
the first three requirements(*), while most likely failing gloriously on
the two last ones.

I'll postpone (b) while I've had a chance to think it over(**), but in the
face of the evidence I'm willing to admit my earlier work estimates (which
should have had a smiley next to them anyway ;-) were in error.

I won't admit to destroying Moscow, though. See (*).

(*) All values depending on the changed cell are marked as invalid before
anything else is done; trying to access an invalid value forces a
recalculation which also marks the cell as valid again, and so on
recursively down to cells that have already converged to a proper value.

Setting input cells in callbacks will f*** that up, though.

(**) Which probably doesn't occur until July or something ;(

> > [Decorator example]
> 
> Wow. I thought Python did not have macros.

Calling decorators macros is an insult to CL macros ;-)
All they do is make it a bit more convinent to apply transformations to
functions, or as the abstract in the original spec[1] says:

  The current method for transforming functions and methods (for instance,
  declaring them as a class or static method) is awkward and can lead to
  code that is difficult to understand. Ideally, these transformations
  should be made at the same point in the code where the declaration
  itself is made.

> This project is looking better all the time. Thx.

In that case I have something else you might like: The "with" Statement[2]

>From the abstract:
    This PEP adds a new statement "with" to the Python language to make
    it possible to factor out standard uses of try/finally statements.

In practice one can use it implement some of the with-macros in a pretty
straightforward manner, especially those that are expanded into
(call-with-* (lambda () , at body)). I believe the previously advertised
with-integrity macro could also be made to work in a satisfying manner.

To quote from the examples:

    2. A template for opening a file that ensures the file is closed
       when the block is left:

        @contextmanager
        def opened(filename, mode="r"):
            f = open(filename, mode)
            try:
                yield f
            finally:
                f.close()

       Used as follows:

        with opened("/etc/passwd") as f:
            for line in f:
                print line.rstrip()

Does that last part look familiar to you?)

The problem with this is that this is Python 2.5 syntax, which currently
appears to be planned for release in late August, a bit late for SoC.
Alpha(*) versions are available, so if you want to take a chance and live
on the bleeding edge, you can probably gain from it.

(*) I don't keep a very close eye on the alpha releases, which is why I
didn't remember this yesterday. I like my programming tools steady
and stable ;-)

[1] http://www.python.org/dev/peps/pep-0318/#abstract
[2] http://www.python.org/dev/peps/pep-0343/
-- 
Lasse Rasinen
lrasinen at iki.fi



More information about the Python-list mailing list