Encapsulation in Python

[Rick Johnson]

On Sunday, March 13, 2016 at 6:35:40 PM UTC-5, Gregory Ewing wrote:
> Unless the module is doing something obscure, you can
> still find [it's source file] by following the chain of
> imports. [...] True, it's not *always* that easy, but in
> the vast majority of cases it is.

I agree you have a valid point, but i'll maintain that in no
way, does this help to relieve the confining nature of these
tightly wrapped "python module diapers", that we are all
forced to wear.

If our "Python motto" is to be, that we're "all adults",
and we can trust our "siblings", and hopefully, *ourselves*,
not to fiddle with aspects of our interfaces that are
considered private, and, private by nothing more, mind you,
than mere *convention*, then why do we take the opposite
approach for modules, and force *ALL* code into a mandatory
"one-size fits all" source file? Our ideology seems to be
inconsistent here. Either we are adults capable of defining
our own code, or we are immature babies who need mommy
Python to protect us from every evil. But we cannot claim to
be both.

And don't misunderstand me, neither form of convention is
"wrong". For instance, Java adopts a strict convention for
writing code, but Java never claimed that it was a language
that promoted "freedom". However, here in the Python
community, we are constantly blabbing about how free we
are, when in fact, our freedom is mostly a delusion. We need
to stop making these false "claims of freedom". Heck, the
only group of people more deluded about their own freedom,
are my fellow Americans (Sometimes i really hate this
country!)

Python does not encourage freedom.

Sure, we enjoy more "degrees of freedom" than say, your
average Java programmer, but we must still submit to the
many inconsistent whims of the Python interpreter. Outside
of indention, we can't define how our code blocks will be
structured. And, outside of nasty hacks, we can't decide how
our module source files will reflect run-time module
namespace. But most disturbing of all, there is no way
possible, to protect the internals of our interfaces from
public meddling.

Many programmers don't understand *WHY* internals need to be
protected. They will scoff at the idea, and they will claim
that, by limiting *THEIR* ability to meddle with internals,
*YOU* are robbing *THEM* of *THEIR* freedom. But what they
don't realize, is that, the only crime worse than failing to
create a proper interface, is to attempt to repair that
failure *EXTERNALLY*.

*ALL* repairs and *ALL* new features must be designed from
*WITHIN* the object that exposes the interface, and from
a strict internal perspective *ONLY*. Whether or not your
language allows it, the following contractual obligations
must *NEVER*, *EVER* be broken:

  (1) Callers can freely make requests to fetch or mutate a
  value, but they are forbidden from fetching and/or
  mutating the value directly. Only the object exposing the
  interface is capable of knowing how best to execute the
  request. If the caller finds that an accessor is missing,
  then the caller should beseech the source code maintainer
  to add the feature, or, they should add the feature
  themselves. But whoever adds the feature, they *MUST* do
  so in a manner that will not violate the basic contract
  between "callers" and "objects exposing an interface".

  (2) How a request is fulfilled, should be of no concern to
  an external caller. The only obligation the caller should
  expect of an interface, is that, when a formal request is
  sent, that a concerted attempt to fulfill the request will
  be made, and, if the request cannot be fulfilled, then a
  suitable explanation must be offered explaining why the
  request could not be fulfilled.

You see, the object exposing the interface is *ALWAYS*
submissive to the requests of any caller, but, if the caller
attempts to break the "accessor contract", by entering the
domain of the object exposing the interface, the object must
block the invader by any means necessary, up to, and
including, the fatal exception.

Basically, the object exposing the interface adopts an
attitude of: "Look, i'll do anything you ask me, so long
as you ask me one of the questions posted on the door, but
you have to make a formal request, you *CANNOT* just enter
this sacred place at will, and start meddling with my
levels and knobs, because if you do, you could cause a
chain reaction that will destroy the delicate balance of
our universe.

I've had the unfortunate experience of maintaining code that
did not utilize "strict interfacing contracts". Heck, for a
good example of what *NOT* to do, have a look at the
idlelib.

  (1) BAD STRUCTURE:  A clear hierarchical structure is
  missing. It's spaghetti code, plain and simple.

  (2) COMPONENT COUPLING: Components are too tightly
  coupled, preventing easy plug-in and/or removal.

  (3) EVENT BINDINGS FIASCO: Instead of creating a "central
  interface" for which *ALL* event bindings would route on
  their way to the main editor widget, the author simply
  applied the bindings "in the shadows", from within various
  modules throughout the libray. Not only is this sort of
  design intuitive, it obfuscates important structural
  details, and it's one of the many reasons why this library
  has rotted for the last 20 or so years!

  (4): EXPORTABLE WIDGETS: Many of the widgets that were
  created for this library would have been useful to Python
  Tkinter GUI programmers over the years, however, they are
  missing much needed documentation, and some are written
  too specifically to be of use outside of IDLE (without
  heavy modifications). Granted, many of these widgets, like
  the Notebook and Balloon, have been offered by TIX for
  sometime, but Tix does not offer anything like Calltips,
  GrepDialog, ReplaceDialog, ClassBrowser., etc...

  But the most important is the Interactive Shell, which, if
  properly componentized, could be utilized to inspect code
  at run-time. It already has syntax coloring, calltips, code
  completion, and what have you. Heck, just the other day on
  Python-list, someone was opining for exactly that!

  (5): GENERAL TOOLS: A few general tools exist that could
  be used in other project..

That's all i can think of at the moment, but it hardly
scratches the surface of what ailes this horrible stdlib
module. Heck, i forgotten more sins of idlelib, than most
people know about it. IDLE is a major failure, and i am
saddened that it has existed in this state for such a long
time.