Encapsulation unpythonic?

[Fabrice Pombet]

On Saturday, August 31, 2013 1:46:52 PM UTC+2, Steven D'Aprano wrote:
> On Fri, 30 Aug 2013 23:07:47 -0700, Fabrice Pombet wrote:
> 
> 
> 
> > well, look at that:
> 
> > 
> 
> > a=(1,2)
> 
> > a=2+3 ->a is an object and I have changed its type and value from
> 
> > outside. 
> 
> 
> 
> Incorrect. You have not changed the type or value of any object. "a" is 
> 
> not an object, it is a *name*, and while you can change the object bound 
> 
> to the name, the objects remain unchanged.
> 
> 
> 
> When you do this:
> 
> 
> 
> x = 23
> 
> x = 42
> 
> 
> 
> the *object* 23 does not change, only the name binding changes. To do 
> 
> otherwise would cause all sorts of surprises:
> 
> 
> 
> # THIS DOES NOT HAPPEN IN PYTHON
> 
> # or any other language, as far as I am aware
> 
> x = 23
> 
> y = x  # y now has the value 23
> 
> x = 42  # change the value of the object  ### NOT SO! ###
> 
> print y
> 
> => prints 42
> 
> 
> 
> Name binding (assignment) does not change objects. It changes the link 
> 
> between a name and the object, but the object remains untouched (unless 
> 
> it is unbound, and garbage collected). Assignment is not mutation. 
> 
> Assigning to a name does not modify the object that was previously bound.
> 
> 
> 
> 
> 
> But even if you were right about changing the type and value of objects 
> 
> in place -- Python allows you to mutate lists and dicts in place, and 
> 
> even mutate the type of some objects, although not built-ins -- your 
> 
> understanding is still confused. Re-assignment (re-binding) of local 
> 
> variables is hardly a violation of encapsulation. But if it was, then 
> 
> Java and C++ have no encapsulation either, because you can re-assign to 
> 
> local variables inside a function too.
> 
> 
> 
> If you want to see a language without encapsulation, you need to look at 
> 
> something like 1970s-style BASIC, a language where all variables are 
> 
> global, where there is no support for grouping related code into separate 
> 
> modules or files, where the closest thing to a function call is GOTO or 
> 
> GOSUB.
> 
> 
> 
> Of course, languages can have *more* or *less* encapsulation than other 
> 
> languages. C lets you encapsulate related functions into a file, but it 
> 
> has no way of grouping data and functions together except loosely, in a 
> 
> file. C++ adds classes, which has more encapsulation since you can group 
> 
> functions and their data together.
> 
> 
> 
> 
> 
> 
> 
> > As far as I am concerned this is one hell of an encapsulation
> 
> > violation... Could you do this -strictly speaking- in Java or C++?
> 
> 
> 
> Of course you could. All you need is a way to tell the compiler not to 
> 
> type-check the variable "a". Or more practically, some way to declare 
> 
> variable "a" as a reference to an untyped or generic value. C# has the 
> 
> dynamic keyword for this functionality. I don't know about Java or C++, 
> 
> but the JVM is certainly capable of implementing dynamic typing as there 
> 
> are various dynamically-typed languages built on top of the JVM, such as 
> 
> OpenXION and Cobra.
> -- 
> 
> Steven

Steve, I think that your definition of encapsulation is too wide to give a reasonable answer to the question at hand. If I understand you correctly, you are taking encapsulation as a language characteristic,  rather than a principle. 
Plus, you seem to forget that encapsulation is an OOP principle, and, forgive me if I am wrong, does not apply normally to functions or languages like C. 
Please read Steve Holden's (in chaz') definition, and tell us whether you think that Python enforces strongly this principle, I think that would be a good basis for an agreement. My answer is no, it doesn't, but it allows you to abide by it if you want to. Unlike Java or C++ who would tend to do exactly the contrary (enforces it strictly, and (possibly?) allow you to discard it at times with a few jiffies (or not? I don't know))