Securing a future for anonymous functions in Python
Carl Banks
invalidemail at aerojockey.com
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
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
> 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
where...do) 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.
Indeed.
--
CARL BANKS
More information about the Python-list
mailing list