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.