[Python-Dev] Re: closure semantics

[Samuele Pedroni]

At 09:40 25.10.2003 -0700, Guido van Rossum wrote:
> > > or at run-time) always goes from inner scope to outer.  While you and
> > > I see nested functions as small amounts of closely-knit code, some
> > > people will go overboard and write functions of hundred lines long
> > > containing dozens of inner functions, which may be categorized into
> >
> > This doesn't look like a legitimate use case to me; i.e., I see no need
> > to distort the language if the benefit goes to such "way overboard" uses.
> > I think they will have serious maintainability problems anyway.
>
>One person here brought up (maybe David Eppstein) that they used this
>approach for coding up extensive algorithms that are functional in
>nature but have a lot of state referenced *during* the computation.
>Whoever it was didn't like using classes because the internal state
>would persist past the lifetime of the calculation.

[seen David Eppstein's post, discarded obsolete comment]

>When I visited Google I met one person who was advocating the same
>coding style -- he was adamant that if he revealed any internal
>details of his algorithm then the users of his library would start
>using them, and he wouldn't be able to change the details in another
>revision.

I should be missing the details, it seems someone unhappy with the 
encapsulation support in Python, wanting it backward using closures. Yes, 
closures can be used to
get strong encapsulation.

If Python wanted again to support directly some form of sandboxed execution 
, then better support for encapsulation would very likely play a role.

But as I said I should be missing something, if the point is stronger 
encapsulation I would add it to the OO part of the language. The 
schizophrenic split, use objects but if you want encapsulation use 
closures, seems odd.

Aside: I have the maybe misled impression, that having a fully complete 
functional programming support in Python was not the point, but that the 
addition of generators have increased the interest in more functional 
programming support.


>AFACT these were both very experienced Python developers who had
>thought about the issue and chosen to write large nested functions.
>
>

they seem to want to import idioms that before 2.1 were not even imaginable,
and maybe I'm wrong, but idioms that come from somewhere else.

Personally, e.g. I would like multi-method support in Python and I know 
where they come from <wink>.

Every experienced Python developer probaly knows some other language, and 
miss or would like something from there.

Sometimes I have the impression that seeing the additions incrementally, 
and already knowing the language well, make it hard to consider the 
learning curve for someone encountering the language for the first time.

I think that evalaluating whether an addition really enhance expressivity, 
or makes the language more uniform vs the ref-man growth is very important.

IMHO generators were a clear win, generator expressions seem a 
add/substract thing because list comprehension explanation becomes just 
list(gen expr).

regards.