Something is rotten in Denmark...

[Jussi Piitulainen]

rusi writes:
> On Jun 5, 5:03 pm, Jussi Piitulainen wrote:
> > rusi writes:
> > > On Jun 3, 11:17 am, Jussi Piitulainen wrote:
> > > > rusi writes:
> > > > > So I tried:
> > > > > Recast the comprehension as a map
> > > > > Rewrite the map into a fmap (functionalmap) to create new bindings
> >
> > > > > def fmap(f,lst):
> > > > >     if not lst: return []
> > > > >     return [f(lst[0])] + fmap(f, lst[1:])
> >
> > > > > Still the same effects.
> >
> > > > > Obviously I am changing it at the wrong place...
> >
> > > >    >>> fs = [(lambda n : n + i) for i in range(10)]
> > > >    >>> [f(1) for f in fs]
> > > >    [10, 10, 10, 10, 10, 10, 10, 10, 10, 10]
> >
> > > >    >>> fs = list(map(lambda i : lambda n : n + i, range(10)))
> > > >    >>> list(map(lambda f : f(1), fs))
> > > >    [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> >
> > > Thanks Jussi for that code -- but I am not fully able to wrap my head
> > > around it.
> >
> > Oops, sorry, I seem to have edited out a question that I meant to ask.
> > The question was this: How do -you- write the list comprehension in
> > terms of your fmap? What -is- the expression that still has the same
> > effects? That is, where do you bind the i's?
> >
> > The obvious-to-me way is shown above, but there it is the outer lambda
> > that establishes the distinct i's for the different closures.
> >
> > (The composition list(map(...)) works in both versions of Python.)
> >
> > > Is the problem in the lambda? ZF?
> > > Are you trying to say that map works (functionally) and ZF is
> > > imperative?
> >
> > Sorry, what is ZF?
> >
> > I'm saying that your fmap works, but in itself it does not provide the
> > bindings that we are talking about, and you didn't show what does. The
> > outer lambda in my example does that.
> >
> > The Python list comprehension [... for i in ...] binds (or assigns to)
> > just one i which is shared by all the closures above. They end up
> > having the same value for i because it's the same i.
> >
> > I hope this is less obscure now.
> 
> I was wondering why the list(...
> Now I see that map returns normal lists in python2 and some generator-
> like-thing in 3
> I would have said: Shall we just stick to 2 (for this discussion) but
> then 2 seems to have a double error that self-corrects this example...
> 
> OOOOFFF -- too many variables...
> 
> [ZF is Zermelo-Fraenkel -- old name for list comprehension  -- I guess
> my age leaks like python's ZF (sorry comprehension) :-) ]

Oh, ok. Zermelo-Fraenkel came to mind, but I didn't know it's been
used as a name for list comprehensions.

> Anyway... My (summary,tentative) conclusion is that python's
> comprehensions leak.
> The one leak fixed in python3 has not fixed the other (revealed in
> this thread)
> 
> All this has little to do with lambda (whose scope rules were fixed
> around python 2.2 IIRC)
> 
> I'd be interested in ur take on this...

I think we agree. I've been saying all along that the perceived
problem is not with the lambda at all but with the way the list
comprehension deals with its variable. (I see that some people
understand the situation correctly but blame the lambda anyway.)

Personally, I like your summary, but I'm enough of an outsider that I
do not want to suggest that there is anything wrong with Python. I
just wish to understand how it works, as with any language that I use.

The issue of this thread seems to turn up repeatedly, but is there a
problem with the language mechanisms, is there a problem with the ways
we talk about the language, or is this just the case where people need
to be educated? I'm not sure.

(Incidentally, I'm so new to Python that I started right with 3.0. I
use some 2.4, 2.5-ish a little because software on a certain server is
not kept updated, but I never knew 2.2.)