Need help with Python scoping rules

[Bruno Desthuilliers]

kj a écrit :
> In <1bf83a7e-f9eb-46ff-84fe-cf42d9608e71 at j21g2000yqe.googlegroups.com> Carl Banks <pavlovevidence at gmail.com> writes:
> 
>> Yeah, it's a little surprising that you can't access class scope from
>> a function, but that has nothing to do with encapsulation.
> 
> It does: it thwarts encapsulation.  The helper function in my
> example is one that clearly rightfully belongs nowhere else than
> the class itself, i.e. encapsulated within the class.

I don't see what's wrong with having this function at the top-level. 
Sorry to have to say it this way, but IMHO you're border on cargo-cult 
thinking here. Python is an all-object language (ie : everything is an 
object, including functions, classes and modules), but it's by no mean 
'pure-object', and module level functions are perfectly ok (and quite 
often the right thing).

Now if you really want to "encapsulate" the function and the class 
together, you do have simple and and working solutions : using a nested 
recursive function (as explained by Diez), or nesting both the class and 
function in a factory function, ie:

def Demo():
   def fact(n):
     if n < 2:
       return 1
     else:
       return n * fact(n - 1)
   class Demo(object):
     _classvar = fact(5)
   return Demo

Demo = Demo()


But anyway: this is really a WTF. Python's notion of encapsulation is 
very weak (by design), and you're really wasting time trying to fight 
the language instead of learning it. Just put that f... helper function 
at the top level (prefixing it's name with a '_' to mark it as 
implementation detail), and move on to something else !-)

>  It is only
> this silly prohibition against recursive functions in a class
> statement that forces one to put it outside the class statement.

The "prohibition" only happens for recursive functions defined *and* 
called in the class statement. And once you get the big picture, it's 
certainly not "silly".