Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> So, fool._bar is now clobbered. Nuts, the _bar attribute is broken for
>> *every* instance of Fools. According to you, the error must be in
>> Fools. Care to point it out?
>
> Yes, the error is in the "breaker" function, which leaks the private
> variable to other classes,
Wrong. The bug is in the King class, which is clobbering objects it's
not supposed to clobber.
Unless your compiler detects and flags passing private variables to
external functions all you've got is a convention that you don't pass
private variables to external functions.
> This is the kind of thing that you'd look for in an audit, so I
> don't see your point.
So would you audit catch this one:
class Fools(object):
... _foo = "my private list of values".split()
... def broken(self):
... return len(self._foo)
...
>>> fool = Fools()
>>> fool.broken()
>>> fool._foo
[]
Are you going to try and tell me thas using builtin functions on
private variables is something you don't allow in your projects?
If all you've got is a convention for some of the cases you're trying
to catch, then having a compiler enforce private variables isn't
fundamentally different from having a convention that you don't touch
variables with specific names. It lets the comiler catch more bugs,
but doesn't mean that such bugs are suddenly impossible.
Of course, there's nothing wrong with catching errors earlier. Might I
suggest that you file a change request for pylint (or your favorite
error checker) asking that it start issuing warnings for
object._variable?
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
