Encapsulation in Python

[Rick Johnson]

On Friday, March 11, 2016 at 3:28:40 AM UTC-6, Steven D'Aprano wrote:

> That's one theory. Another theory is: no they shouldn't, all attributes
> should be public. That most accurately models actual physical objects and
> maximizes the usefulness of the attribute.
> 
> People over-use private, and if you google, you will find many people
> asking "how can I access private variables and methods?".

If "people" are trying to access private variables, then one, or both, 
of these  has occurred: (1) The interface was poorly
written, and/or (2) The user of the interface is hell bent
on shooting himself in the foot!

> Python offers a middle ground: where encapsulation is important for safety,
> use it, otherwise rely on trust and a gentleman's agreement. We're all
> adults here: if you use my internals, that's your choice, and you can live
> with the consequences.
> 
> In practice this means that internal details of classes written in C are
> completely hidden from Python code unless explicitly made public. Why?
> Because if the caller messes with the internal data of a C class, they can
> cause a segmentation fault, which can execute arbitrary code. This is a
> serious problem, and Python has a philosophy of Absolutely No Seg Faults.

First you go off blabbing about how all attributes should be
public, then you do an about face, and admit that very bad
things can happen when internals are exposed. Does anyone
else find this argument to be absurd?

> It should be impossible to cause the Python interpreter to seg fault or
> dump core (except via ctypes, which is special). 

SPECIAL CASES ARE *NOT* SPECIAL ENOUGH TO BREAK THE RULES!

> But what about Python classes? You can't cause a seg fault in Python code.

Are you sure about that? Heck, i posted code quite a few
years back that "seg faulted like a mutha". Do you want to
retract your statement, or will i need to search the
archives, and then stuff the link down your big fat mouth?

> So Python's philosophy is:
> 
> - trying to *enforce* private data is a waste of time, people will find a
> way around it, even if it is a horrible nasty hack;
> 
> - so instead, rely on trust: we mark "private" attributes with a leading
> underscore, and trust that users won't abuse them;
> 
> - if they do, the consequences are on their head, not ours: you have no
> responsibility to users who misuse your private attributes.

I theory, that is a great philosophy, but in practice, it
encourages people to be lazy, and they end up writing
horrible interfaces. Why spend the time to write a proper
interface, when, in the back of your mind, you know you can
reach into that public cookie jar *ANYTIME* you want to.
It's like when an overweight person goes on a diet, but still 
has cookies, cakes and ice-cream in the kitchen -- the
temptation to be a slob is just too great!

Imagine if indention were optional in Python, or if Python
allowed braces... Even with all the benefits of indention
over braces, quite a few idiots would still use the damn
braces! Heck, i knew this one Ruby coder, who was a longtime
C coder, and at the end of every line, he religiously placed
a semicolon there. And i told him, "dude, you're *NOT*
writing C code anymore, so stop putting those damn trailing
semicolons in your source!". But the arrogant bassturd
refused to stop. So i thought: "Hmm, maybe it's just a bad
habit", but no, he freely admitted that he conscientiously
placed them in hos source because: "he liked them".

There are two main methods that a language can ruin you as a
programmer. One method is to encourage you to be a "Lazy
Larry", and the other is to mold you into a "habitual
Harry". Python has mostly eradicated the "habitual Harry"
disease, but it still actively promotes the "lazy Larry"
disease. Yes, pure OOP is onerous to the programmer, but it
is onerous for a reason. And that *REASON* is to create
rigid interfaces!

Anytime a standard is handed down, people are going to
whine.

 "WAH, standards are hard!"
 
 "WAH, it takes too long!" 
 
 "WAH, my fingers hurt!"
 
But what these whiners don't realize, is that, either they
put in the effort of writing solid interfaces *NOW*, or they
will be forced to debug, explain, and repair the awful
interfaces *LATER*.  In the end, there is no shortcut to
excellence. Which brings me back to my motto: "Great
interfaces *NEVER* happen by accident --shite happens,
interfaces don't!"

Yes, creating proper interfaces requires a lot of thought, a
lot of testing, and yes, a whoooole lot of typing. But if
thinking, and testing, and typing are not your thing, then
perhaps you'd be happier smoking marijuana and working as
sales associate at your local GAP store.