Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!newsfeed.eweka.nl!eweka.nl!feeder3.eweka.nl!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <761032ae-6c92-4b80-b287-e158ece7582e@kt16g2000pbb.googlegroups.com>
References: <k6mb4k$5v3$1@news.albasani.net> <761032ae-6c92-4b80-b287-e158ece7582e@kt16g2000pbb.googlegroups.com>
Date: Tue, 30 Oct 2012 14:15:09 +0000
Subject: Re: Nice solution wanted: Hide internal interfaces
From: andrea crotti <andrea.crotti.0@gmail.com>
To: alex23 <wuwei23@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3092.1351606518.27098.python-list@python.org>
Lines: 67
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:32492

2012/10/30 alex23 <wuwei23@gmail.com>:
> On Oct 30, 2:33 am, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
>> 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.
>
> One approach could be to only have the public interface on B, and then
> create a wrapper for B that provides the private interface:
>
>     class B:
>         def public_method(self):
>             pass
>
>     class B_Private:
>         def __init__(self, context):
>             self.context = context
>
>         def private_method(self):
>             # manipulate self.context
>
>     class A:
>         def __init__(self):
>             self.b = B()
>             self.b_private = B_Private(self.b)
>
>         def foo(self):
>             # call public method
>             self.b.public_method()
>
>             # call private method
>             self.b_private.private_method()
>
> It doesn't stop a user from accessing the private methods, but it does
> separate them so they have to *intentionally* choose to use them.
> --
> http://mail.python.org/mailman/listinfo/python-list



Partly unrelated, but you could also define a clear API and expose it
through your __init__.py.

For example:
package/a.py:
class A: pass

package/b.py:
class B:pass

package/__init__.py
from a import A

so now doing "from package import" will only show A.

This doesn't work on the method-level, but it's useful to know and
commonly done in many projects..


In some projects they even use a file "api.py" to you have to
explicitly import

from package.api import ..
(which I think is overkill since __init__.py does the same)