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

[Bob Ippolito]

On 2004-03-02 01:24:04 -0500, michele.simionato at poste.it (Michele 
Simionato) said:

> michele.simionato at poste.it (Michele Simionato) wrote in message 
> news:<95aa1afa.0403010014.4222ce8e at posting.google.com>...
>> 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
> 
> Just to add another data point, I asked on comp.lang.functional and 
> discovered that Haskell list comprehension works as I would expect,
> i.e. differently from Python:
> 
> Prelude> let make-adders n = [ \x -> x + i | i <- [0..n-1] ]
> Prelude> let [add0,add1] = make_adders 2
> Prelude> add0 0
> 0
> Prelude> add1 0
> 1
> 
> So, it looks like as if Haskell implements the idea I exposed.
> Still, it is to be discussed if the idea makes sense in Python.
> 
> 1. Assuming all "for" loops and list comprehensions are replaced
>    with Haskell bindings rules, what about backward compatibility
>    problems? For instance: is there enough code relying on the loop    
> variable being available outside the loop?
> 
> 2. If, due to compatibility issues, it is not possible to change the
>    binding rules of existing loops, would it make sense to propose
>    these binding rules for Python 2.4 generator comprehension?
>    This would not be backward incompatible, but would it generate
>    confusion?

It could always be a __future__

> 3. Assuming the rules can be changed without real trouble, is the feature
>    worth enough? Do people care about it, and is there somebody willing
>    to take the job?

I know that I've been bitten by this before, but after doing it once or 
twice you learn how to get around it.. the biggest problem I have with 
list comprehensions is that I think they should have the same scoping 
rules as an inner function would, as opposed to a for loop (i.e., 
shouldn't pollute namespace).

-bob