encapsulation checking features

[Eric Scharff]

Thanks for the reference to PyChecker, I'll have to check it out.

I've not read enough python code to know how people traditionally treat
"instance variables that ought to be public" and "instance variables that
ought to be private" (other than prepending underscores, which I never
liked).

> But I really don't see the problem here.  If you want myVar.x to
> call an accessor, you make x into a property of myVar's class,
> period.  Absolutely no need to design trivial do-nothing accessors
> either -- you can perfectly well have all client code access all
> instance variables you want, and if and then such "variables"
> need to be "computed on the fly" or have special effects when
> set, then you make them into properties, hey presto.

I come from a Smalltalk background, which implicitly treats all direct
variable references as private to a class, requiring do-nothing accessors.
The advantage of these in Smalltalk is that I find it makes refactoring
easier - you can ask Smalltalk to tell you everywhere where the "myVar:"
setter is called.  I could grep all of my python code for ".myVar =" but
that technique is slightly less accurate.

>> These are great features to have, but it'd be nice to have warnings to
>> discourage their use at times.

> I can see that for the "ensure all instance variables exist at
> the end of __init__".  I can't see that, given the existence of
> properties, for "no access to instance attributes from outside
> of methods".  Perhaps you can clarify what advantage the latter
> would provide, that properties just can't...?

Here's an example:  I implemented a simulation of something using python
objects that represent objects in the simulation.  In my rapid prototyping,
the objects had two "aspects", the simulation and the visualization.  Every
object had a tkItem instance variable that the object used to configure
using Tkinter.  Now, I want to create an easy way to enable and disable the
views, or have more flexible views.  Turning off the visualization means
finding all the references to tkItems and changing their structure.

Yes, it was badly written to start, but it made sense at the time. :)  Now
I want to get as much built-in help for refactoring as possible.

-Eric