Need help with Python scoping rules
bruno.42.desthuilliers at websiteburo.invalid
Thu Aug 27 10:35:51 CEST 2009
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:
if n < 2:
return n * fact(n - 1)
_classvar = fact(5)
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".
More information about the Python-list