Securing a future for anonymous functions in Python

Bengt Richter bokr at
Tue Jan 11 05:25:59 EST 2005

On Mon, 10 Jan 2005 21:15:50 -0500, Tim Peters <tim.peters at> wrote:

>>> 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 one
>> 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
Well, I did say it reminded me of some kind of weird let ;-)

>seems a more natural fit to Python's spelling of block structure:
>    let:
>        suite
>    in:
>        suite
>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.
I could get to like it ;-)

Hm, a little extension to this could provide a new way to populate closure variables,
and also (never mind, one thing at a time ;-)

#1: If you gave your 'let' above a list of 'externs' that can be rebound from within the let.


the effect in your example would be to eliminate the NameError you mention.
The compiler would make an entry for sqrt in the enclosing namespace, and generate
code to bind/rebind if assigned from within the let.

This would be an interesting way to create closure bindings:

        preset = 'another way to make closure vairables'
        def foo(): return preset
    print foo()

#2: Making the in: suite callable as a light weight function with no arguments. An optional
binding name after in would bind like def and create a persistent named callable instead of just an
implicitly called anonymous suite.

Then you could define the same effective foo by

        preset = 'another way to make closure vairables'
    in foo:
        return preset  # return now legal 
    print foo()

The combination would work like:

        factor = 10
    in bar:
        rebindable *= factor

    rebindable = 2
    print rebindable  # => 20
    rebindable += 5
    print rebindable  # => 250

You can see this could be used nicely in case functionality, with a dict of named in-functions.

What do you think?

Bengt Richter

More information about the Python-list mailing list