Encapsulation unpythonic?

[Fabrice Pombet]

On Saturday, August 31, 2013 4:35:39 AM UTC+2, Steven D'Aprano wrote:
> 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?
> 
most people(except you, apparently, but I fear that you do not really accept in general)
> 
> 
> 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?

See above me chaz... at gmail.com, the definition of encapsulation from his OST course is fine by y standards, quoting him:
"I'm taking the Python Cert series w/ O'Reilly School of Technology, which I recommend if you've got a good handle on OO programming.  In any event, according to what I've learned, "encapsulation is the idea that the only way to access or change the data inside an object is by calling its methods. This idea has never really gained much ground in the Python world, and it is normally considered acceptable to both read and set an object's attributes from anywhere in a program." 

Keep in mind that we are talking about Encapsulation(a general/philosophical principle) as opposed to encapsulating (i.e. setting an argument so that it can only be read/written from within its class/object)
this is a key conceptual point. I agree with you that Python allows you to enforce the encapsulation principle within your code, whenever you want it. But not as a principle that you NEED to respect(as in Java for instance). It is, in my opinion, much better this way. 

> 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...
> 
I am no academic, and I think that's right.
> 
> 
> 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.
> 
> 
I think that I prefer chaz' definition (it is, how could I put it... A tad easier to understand)
> 
> 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

well, look at that:

a=(1,2)
a=2+3 ->a is an object and I have changed its type and value from outside. As far as I am concerned this is one hell of an encapsulation violation... Could you do this -strictly speaking- in Java or C++?