kj a écrit :
In <1bf83a7e-f9eb-46ff-84fe-cf42d9608...@j21g2000yqe.googlegroups.com> Carl Banks
<pavlovevide...@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".
--
http://mail.python.org/mailman/listinfo/python-list
