Feature request: subclassing FunctionType [Was: Some language proposals]

[Michele Simionato]

Thinking a bit more, the issue is not about the scope rules, it is about
how the "for" loop is interpreted. Currently

for i in iterable:
    <do_something i>

is interpreted as

try:
    it=iter(iterable)
    while True:
        i=it.next()
        <do_something i>
except StopIteration:
    pass

The issue would disappear if the "for" loop included an hidden function
call and was interpreted as follows:

try:   
    it=iter(iterable)
    def helper(i):
        <do_something i>
    while True:
        helper(it.next())
except StopIteration:
    pass

For instance, in the example I am talking about,

def make_adders(n):
    return [lambda x: x+i for i in range(n)]

would be interpreted as

def make_adders(n):
    try:
        adders=[]
        it=iter(range(2))
        def helper(i):
            adders.append(lambda x: x+i)
        while True:
            helper(it.next())
    except StopIteration:
        return adders

Essentially, the "i" variable would be passed via the helper function
call and at each iteration the lambda function would see a different
value of it.

I am proposing nothing here, just asking if it would make sense to
have a looping construct acting this way (my guess is that this
has already been proposed and discussed). This would have
the added benefit of avoiding a non-local loop variable (i.e. a
loop variable which exists even outside the loop) which is the
actual unfortunate behavior.

       Michele Simionato