Encapsulation in Python

[Rick Johnson]

On Saturday, March 12, 2016 at 10:45:43 AM UTC-6, Ian 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? 

I use words, mostly.

> > [SNIP: Two Examples From Rick]
>
> Is this meant to be equivalent to the other example? In that example,
> you have the two "satellite" modules being imported between the
> definition of FOO_SHARED_STATE and the print. In this example, how on
> Earth is Python supposed to know that after the FOO_SHARED_STATE line
> it's supposed to switch to executing these other two files before
> continuing on to the next statement?

The examples i provided are too simplistic to convey such
details, because they were never meant to convey such
details. Of *COURSE* you'll encounter issues in *real code*
if you don't organize it's execution correctly. Spreading
the contents of a module across multiple source files does
not prevent NameErrors from raising, and it shouldn't. Heck,
you can easily break a python module today, by referencing
a symbol too early:

    ##############
    # example.py #
    ##############
    bar = Bar()   
     
    class Bar(object):
        pass

> > That sounds simple in theory, but it breaks down quickly
> > when you create "professional sized programs"
> 
> I find in interesting that you seem to be equating "very large" with
> "professional". In my view, it's exactly the opposite. Anything very
> large and so unorganized looks rather sloppy and unprofessional.

I find it interesting that you seem to be equating "very
large" with "sloppy". Not all large software's are sloppy,
and not all small software's are neat. Dealing in absolutes
is never a good idea.

> >> 3) Just put all your damn shared state in a class. There's nothing
> >> stopping you from spreading out your class method definitions over
> >> multiple files if you really want to, and it solves your import issue
> >> by allowing everything to be imported before you even begin to set up
> >> the shared state.
> >
> > Your words tell me that you have not written anything substantial.
> 
> I'll take your lack of substantive reply to mean "Huh, I never thought
> of this approach that both solves my problem and improves the
> structure of my code at the same time. Better hurl an insult to save
> face!" Compliment accepted.

Why must I invoke the awesome "instancing power" of a
SharedStateObject, when a singleton would be a more
appropriate design? But even a singleton would be a nasty
hack for: sharing state across a "module space" that is 
defined in multiple source files.