Securing a future for anonymous functions in Python

Carl Banks invalidemail at
Tue Jan 11 06:06:48 EST 2005

Tim Peters wrote:
> ...
> [Anna]
> >> BTW - I am *quite* happy with the proposal for "where:" syntax - I
> >> think it handles the problems I have with lambda quite handily.
> [Steve Holden]
> > Whereas I find it to be an excrescence, proving (I suppose) that
> > man's meat is another person's poison, or something.
> I've been waiting for someone to mention this, but looks like nobody
> will, so I'm elected. Modern functional languages generally have two
> forms of local-name definition, following common mathematical
> conventions.  "where" was discussed here.  The other is "let/in", and
> seems a more natural fit to Python's spelling of block structure:
>     let:
>         suite
>     in:
>         suite

Ah.  During that discussion, I did kind of suggest this (spelling it as an alternative to where (thinking I was clever).  Only
no one seemed to take notice, probably because I suggested something
more poignant at the same time.

Now I see why I liked the idea so much; it was exactly like let forms.

> There's no restriction to expressions here.  I suppose that, like the
> body of a class, the `let` suite is executed starting with a
> conceptually empty local namespace, and whatever the suite binds to a
> local name becomes a temporary binding in the `in` suite (like
> whatever a class body binds to local names becomes the initial value
> of the class __dict__).  So, e.g.,
>     i = i1 = 3
>     let:
>         i1 = i+1
>         from math import sqrt
>     in:
>         print i1, sqrt(i1)
>     print i1,
>     print sqrt(i1)
> would print
>     4 2
>     3
> and then blow up with a NameError.
> LIke it or not, it doesn't seem as strained as trying to pile more
> gimmicks on Python expressions.



More information about the Python-list mailing list