Encapsulation in Python

[Steven D'Aprano]

On Sun, 13 Mar 2016 03:44 am, Ian Kelly wrote:

> On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson
> <rantingrickjohnson at gmail.com> wrote:
>> At run-time, i don't care how large a "module namespace" may
>> be. Sometimes a module namespace will be small, with only a
>> few exposed symbols, but sometimes, a module namespace will
>> expose thousands of symbols.
> 
> Thousands, really? What system do you use to ensure that symbols don't
> accidentally collide with one another? Because, you know, Python won't
> check this for you even within a single file, unlike say C++ which
> does allow splitting namespaces across multiple files. A linter might,
> but not at runtime, and I don't expect it will be smart enough to
> notice if the definitions are in different files.


I would hate to use an API with "thousands" of symbols in a single
namespace. I find `os` difficult enough, and it has less than a quarter
thousand:

py> len(dir(os))
224


The decimal module is, in my opinion, about as big as a module should ever
get before it becomes too unwieldy to maintain, and it has less than a
hundred symbols:

py> len(dir(decimal))
79


While it is true that the Zen says "Flat is better than nested", it does
also say

    Namespaces are one honking great idea -- let's do more of those!


so at the point that your namespace has more symbols than can be managed by
the merely mortal, then it's well past time to split some of them off into
separate namespaces.


[...]
>> But option two is no better, because once we cut and paste
>> portions of the code into satellite files, we lose the
>> ability to "easily share state". Then we're forced to start
>> "hacking at the weeds" with import contortions and monkey
>> patches, all the while, fearing the dreaded circular import.
>>
>>
>> NO, THIS IS INSANITY!  WHAT WE NEED IS AN OPTION 3!

What we actually need is a way to have less shared state. If you have so
much shared state that you cannot manage it in a single module, you have a
problem no matter what you do.



-- 
Steven