Home Original page

Encapsulation in Python

Chris Angelico rosuav at gmail.com
Sat Mar 12 16:10:35 EST 2016 
On Sun, Mar 13, 2016 at 3:49 AM, Rick Johnson
<rantingrickjohnson at gmail.com> wrote:
> Imagine this scenario:
>
>     ####################
>     # currentModule.py #
>     ####################
>     from modX import foo
>
>     def bar():
>         return foo()
>
>     ###########
>     # modX.py #
>     ###########
>     from modY import foo
>
>     ###########
>     # modY.py #
>     ###########
>     from modZ import foo
>
>     ###########
>     # modZ.py #
>     ###########
>     def foo():
>         return 'O:-)'
>
> I'll admit this is a highly contrived example, but it is not
> invalid in anyway, and could therefore exist in reality.

I've never seen public symbols deliberately being imported through
multiple levels like this. The most I've seen is __init__.py pulling
stuff in from one of its modules (eg "from .constants import *"), or a
Python module importing from its accelerator ("from _socket import
*"). In theory, I suppose you could have both at once, but that's the
most you'd ever get, and the three would be very tightly coupled.
Otherwise, this simply doesn't happen.

Also, if currentModule.py is pulling foo from modX, then modZ.py is an
implementation detail. You don't necessarily want to go straight
there; tracing the chain is more likely to be the correct behaviour.
Suppose modX.py actually looks like this:

if 'posix' in some_magic:
    import posixY as modY
elif 'nt' in some_magic:
    import ntY as modY
else:
    raise ImportError

The correct way to find out where modX.foo comes from is to look at
this block, not to jump right through it. Law of Demeter - you take
things one step at a time (unless there's a good reason).

ChrisA
More information about the Python-list mailing list