In article <200310251640.h9PGePZ07536@12-236-54-216.client.attbi.com>, Guido van Rossum <guido@python.org> 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.
Yes, that was me. You recommended refactoring the stateful part of the algorithm as an object despite its lack of persistence. It worked and my code is much improved thereby. Specifically, I recognized that one of the outer level functions of my code was appending to a sequence of strings, so I turned that function into the next() method of an iterator object, and the other nested functions became other methods of the same object. I'm not sure how much of the improvement was due to using an object-oriented architecture and how much was due to the effort of refactoring in general, but you convinced me that using an object to represent shared state explicitly rather than doing it implicitly by nested function scoping can be a good idea. -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science