Encapsulation in Python

[Chris Angelico]

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