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