Home Original page

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

Michele Simionato michele.simionato at poste.it
Tue Mar 2 01:24:04 EST 2004 
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?

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? 


     Michele Simionato
More information about the Python-list mailing list