optimization

[Carl Banks]

On Dec 2, 1:56 pm, Neal Becker <ndbeck... at gmail.com> wrote:
> Robert Kern wrote:
> > Neal Becker wrote:
> >> Arnaud Delobelle wrote:
>
> >>> Neal Becker <ndbeck... at gmail.com> writes:
>
> >>>> I noticed in some profiling, that it seems that:
>
> >>>> def Func ():
> >>>>   def something():
> >>>>     ...
>
> >>>> It appears that if Func is called many times, this nested func
> >>>> definition will cause significant overhead.  Is this true?  I guess
> >>>> I've become accustomed to decent compilers performing reasonable
> >>>> transformations and so have tended to write code for clarity.
> >>> If something() can be defined outside Func(), how is it clearer to
> >>> define it inside?
>
> >> If it's only used inside.
>
> > I, for one, find that significantly less clear. I only expect functions to
> > be defined inside of functions if they are going to use lexical scoping
> > for some reason. If I read your code, I'd probably waste a good five
> > minutes trying to figure out what part of the local scope you were using
> > before I would conclude that you just did it because you thought it looked
> > better.
>
> I'm using the inner function to prevent pollution of the global
> namespace.  Local variables also have this attribute.  Code is
> easier to understand when it is written with the greatest locality
> - so you can see immediately that the inner function isn't used
> somewhere else.

Let me throw this out:

The rule-of-thumb should not be whether something is used anywhere
else, but rather if it is modified locally or depends on something
that exists locally.  Use outer scope when possible, inner scope only
when necessary.  Flat is better than nested.

In this case, local variables are different from locally-defined
functions, because local variables are typically rebound over the
course of the function, or are constant but depend on the function's
arguments.  (Variables that aren't rebound within the function, or
don't depend on the arguments, are considered constants and are
typically defined in all caps at the module level.)  Locally-defined
functions, however, are constant, and unless they use values from the
enclosing scope, they do not depend on the local environment.
Therefore, by this criterion, the locally-defined function ought to be
defined at the module level, just like constants are.

I don't buy that nesting functions prevents namespace pollution.
IMHO, namespace pollution occurs when you do things like "from module
import *"; there is no pollution when you control the whole namespace
yourself.


Having said that, I do use local functions without closures here and
there, when it's something either too silly or too specific to
introduce a module-level function for.  Judgment call, mostly, but
typically I go to the module level.


Carl Banks