Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #32492
| References | <k6mb4k$5v3$1@news.albasani.net> <761032ae-6c92-4b80-b287-e158ece7582e@kt16g2000pbb.googlegroups.com> |
|---|---|
| Date | 2012-10-30 14:15 +0000 |
| Subject | Re: Nice solution wanted: Hide internal interfaces |
| From | andrea crotti <andrea.crotti.0@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.3092.1351606518.27098.python-list@python.org> (permalink) |
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)
Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread
Nice solution wanted: Hide internal interfaces Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-10-29 17:33 +0100
Re: Nice solution wanted: Hide internal interfaces andrea crotti <andrea.crotti.0@gmail.com> - 2012-10-29 16:41 +0000
Re: Nice solution wanted: Hide internal interfaces Benjamin Kaplan <benjamin.kaplan@case.edu> - 2012-10-29 09:41 -0700
Re: Nice solution wanted: Hide internal interfaces Chris Angelico <rosuav@gmail.com> - 2012-10-30 03:47 +1100
Re: Nice solution wanted: Hide internal interfaces Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-10-29 17:58 +0100
Re: Nice solution wanted: Hide internal interfaces Paul Rubin <no.email@nospam.invalid> - 2012-10-29 10:03 -0700
Re: Nice solution wanted: Hide internal interfaces Grant Edwards <invalid@invalid.invalid> - 2012-10-29 18:00 +0000
Re: Nice solution wanted: Hide internal interfaces Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-29 13:09 -0600
Re: Nice solution wanted: Hide internal interfaces Grant Edwards <invalid@invalid.invalid> - 2012-10-29 16:52 +0000
Re: Nice solution wanted: Hide internal interfaces Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-10-29 18:01 +0100
Re: Nice solution wanted: Hide internal interfaces Peter Otten <__peter__@web.de> - 2012-10-29 18:17 +0100
Re: Nice solution wanted: Hide internal interfaces Peter Otten <__peter__@web.de> - 2012-10-29 18:06 +0100
Re: Nice solution wanted: Hide internal interfaces Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-29 22:37 +0000
Re: Nice solution wanted: Hide internal interfaces alex23 <wuwei23@gmail.com> - 2012-10-29 18:37 -0700
Re: Nice solution wanted: Hide internal interfaces andrea crotti <andrea.crotti.0@gmail.com> - 2012-10-30 14:15 +0000
csiph-web