Home Original page

allowing braces around suites

Antoon Pardon apardon at forel.vub.ac.be
Fri Sep 3 03:02:16 EDT 2004 
Op 2004-09-02, Jeff Shannon schreef <jeff at ccvcorp.com>:
> Antoon Pardon wrote:
>
>>Suppose you have the following situation:
>>
>>|  def function
>>|
>>|    def localfunction
>>|
>>|      localfunction
>>|      code
>>|
>>|    function
>>|    code
>>
>>My experience is that in such a situation, especially
>>if the local functions grows of you have more 
>>local functions it can become hard to see where the body
>>of the global function begins. 
>>
>
> My experience is that defining local functions inside of parent 
> functions is not a good way to deal with this situation.

What kind of sitution do you mean here? Just the fact that
it becomes difficult to distinghuish the start of the main
function?

> I would, 
> instead, write this as two separate module-level functions, one of which 
> calls the other, and possibly indicating one of them as non-public via 
> naming convention:

I don't understand this. You are putting a function that logically
belongs inside an other function and makeing it non-public somehow
all to avoid using an end marker to seperate the local function
code from the main function code.


> def mainfunction():
>     x = y + z
>     result = []
>     for n in range(x):
>         result.append( _subfunction(n) )
>     result.sort()
>     return mylibrary.modify(result)
>
> def _subfunction(n):
>     if n > 5:
>         while n:
>             x, n = dostuff(n)
>     else:
>         x = math.sqrt(x)
>     return x
>
> Regardless of whether _subfunction() will ever be used anywhere else, I 
> wouldn't define it inside of mainfunction().  (The only use I see for 
> inner functions is to construct a function whose structure depends on 
> outer-function data in a way that can't be reasonably expressed with a 
> parameter -- and I see few cases of that.

But if you want a function to avoid a certain level of nesting, chances
that you need such a function increase.

> Otherwise, the only gain from 
> defining an inner function is name-hiding, and I find the complexity 
> cost of inner functions to be much higher than the insignificant benefit 
> gained by name-hiding.) 

Personnaly I think local functions decrease complexity, because it
reduces the points where a function can be called and thus reduces the
possible interaction of the function with the rest of the code.

But to each his own.

-- 
Antoon Pardon
More information about the Python-list mailing list