Q: Python 2.0 preliminary features?

[Tim Peters]

[Eric Jacobs, cogitating about nested functions & lexical scopes]
> ...
> But that would be very tricky to do for functions, because
> sub-functions are first class and can exist even when their
> containing function has exited. If the sub-function chained
> to the containing function's namespace, that would mean that
> the whole stack frame would essentially have to be moved
> to a "heap frame" and ref-counted and handled like an
> independent object!

Heh heh.  Python already does all of that (frames are heap-allocated
already, and are refcounted like everything else):

>>> try:
...     raise "error"
... except:
...     import sys
...     print sys.exc_info()[2].tb_frame
>>>
<frame object at 80c5b0>
>>>

The only technical hangup in implementing lexical closures is that it
creates cycles among internal objects, which refcounting can't reclaim.
Greg Ewing recently worked up a patch that implements "read only" lexical
closures, that avoids the cycles in many (most, or almost all, for most, or
almost all <wink>, common programming styles) cases, albeit with some other
costs (see DejaNews).

It may (or may not) be revealing that people who have used Python since The
Beginning don't agitate for this.  Python's current "two-level" scoping has
charms of it own; abuse of the default argument mechanism to simulate
closures by hand makes it very explicit which names leak across the scope
boundary; and creating a class is often a much better way to manage a
namespace with indefinite extent.  I expect the pressure for lexical
closures will prove too intense to withstand, but even as a retired
functional-language fan I don't think they'd really add anything to
Python -- apart from the opportunity to pretend you're programming in some
other language <0.9 wink>.

flat-is-better-than-nested-ly y'rs  - tim