Nice solution wanted: Hide internal interfaces

Steven D'Aprano steve+comp.lang.python at pearwood.info
Mon Oct 29 18:37:01 EDT 2012


On Mon, 29 Oct 2012 17:33:24 +0100, Johannes Bauer wrote:

> Hi there,
> 
> I'm currently looking for a good solution to the following problem: I
> have two classes A and B, which interact with each other and which
> interact with the user. Instances of B are always created by A.
> 
> Now I want A to call some private methods of B and vice versa (i.e. what
> C++ "friends" are), but I want to make it hard for the user to call
> these private methods.

In B, name these private methods with a leading underscore, exactly as 
you would for any other private name, e.g. B._method.

Do not document the existence of B._method in external documentation 
aimed at the user, except to note that all methods with leading 
underscores are private, and the use of them is unsupported and subject 
to change without notice.

In A, use B._method normally. After all, it's *your* code, you can do 
whatever you see fit.


> Currently my ugly approach is this: I delare the internal methods
> private (hide from user). Then I have a function which gives me a
> dictionary of callbacks to the private functions of the other objects.
> This is in my opinion pretty ugly (but it works and does what I want).

Seems to me that this dictionary of callbacks does nothing but add 
unnecessary complexity to your code. What's the point of it?

Besides, if your users are foolish enough to use flagged private 
_methods, they're foolish enough to access the functions in the callback 
dictionary. So you gain nothing but extra work.



-- 
Steven



More information about the Python-list mailing list