Encapsulation unpythonic?

[Steven D'Aprano]

On Fri, 30 Aug 2013 10:43:28 -0700, Fabrice Pombet wrote:

> On Saturday, August 17, 2013 2:26:32 PM UTC+2, Fernando Saldanha wrote:

>> 2) If it is in fact true that encapsulation is rarely used, how do I
>> deal with the fact that other programmers can easily alter the values
>> of members of my classes?
>> 
> Fernando, it is widely accepted that Python pays very little attention
> to encapsulation as a principle set in stone.

Widely accepted by whom?

Python code is *full* of encapsulation. Functions, methods, classes, 
modules, packages, even local variables, are all mechanisms for 
encapsulating code and data. Those who say that Python has little or no 
encapsulation are talking rubbish.


> Chaz's definition of
> encapsulation is also mine.

Who is Chaz, and what definition does he have?


> Now you need to consider that taking this
> principle off the hostel of OOP does not mean that you can do whatever
> you fancy and you can't make anything unsettable.
> 
> There are plenty of techniques within Python that allow you to protect
> your arguments (in particular, decorators) inside a Class.

And now you are talking about information hiding and protection, which is 
not the same of encapsulation, no matter what the academics think. 
Sometimes the air gets a bit too thin to breathe way up at the top of 
those ivory towers...

Encapsulation is about grouping code that needs to be together together. 
In contract, you have programming languages that give you little, or 
nothing, in the way of grouping -- everything is one big chunk of code, 
with GOTO or GOSUB to jump from place to place.

Functions and procedures are the first, most simple, form of 
encapsulation. Classes allow you to encapsulate multiple functions 
("methods") together with the data they need to operate on in one chunk. 
Even in C++ or Java, you can have classes that provide no information 
hiding at all -- just declare everything "public".

On the other hand, non-OOP languages like C can implement information 
hiding. In C, you can hide information from other files by declaring them 
as "static". Variables declared inside a brace-delimited block only exist 
within that block: local variables are hidden. For example:

    int foo;
    static int bar;


bar is hidden from other files. Likewise, in this function:

     
    int func(void) {
       int baz;
       ...
    }


baz is local to func, and invisible to any other function.

So you can have information hiding without classes, and classes without 
information hiding. The two concepts are obviously independent, but as 
usual, the academics who are in love with OOP like to pretend that 
anything that is of any interest whatsoever in computing was invented by 
Java and C++.

There are even languages with functions, but no local variables. For 
instance, older versions of Forth let you define functions, what Forth 
calls "words", but all functions operate on the same global stack.

Python has excellent encapsulation: we can combine code that ought to be 
together into a function, related functions into a class, related classes 
into a module, and related modules into a package.


> Now, lets get to the pretentious philosophical discussion: I guess
> encapsulation is quite the opposite of, say, dynamic typing, which is
> arguably core in Python. 

They are utterly unrelated. Dynamic typing has nothing to do with whether 
or not you can encapsulate code into chunks (subroutines, functions, 
modules, classes...) or whether you have to write one big amorphous 
unstructured program where every chunk of code can reach inside other 
chunks of code. Nor does dynamic type have to do with information hiding. 
You can have a private member of a class regardless of whether that 
member has a single fixed type enforced at compile-time, or a dynamically 
typed value enforced at run-time.



-- 
Steven