A java hobbyist programmer learning python

[TheFlyingDutchman]

>
> * No getters and setters. Python takes a very permissive approach to
> class attributes, taking the philosophy "we're all adults here". It's
> easy to change a public attribute to a private attribute with a getter/
> setter if you need to, so there's nothing to be gained by writing getters
> for straight attribute access. It just makes things slow.

If adding a getter/setter made data private, then per a tenet of
Object Oriented Programming, there would be something to be gained
from it. But I don't see getter/setters would do that.

The statically typed object oriented languages, like Java, C++ and C#,
all permit member data and functions to be public - allowing a
programmer to implement a "we're all adults here" programming
philosophy if they so choose. However, they also allow a programmer to
make member data and functions private, thus allowing the
implementation one of the tenets of OOP. I don't use Ruby, a
dynamically typed language like Python, but from a web search it
appears that Ruby does allow at least data to be declared private. But
it appears that a user of a class can get around this private
declaration by writing their own methods and adding them to the class
dynamically.

In his book "Core Python Programming", noted Python expert and PyCon
speaker Wesley J. Chun makes the following statements regarding one of
the main principles of Object Oriented Programming (OOP):

"Encapsulation/Interfaces
Encapsulation describes the concept of data/information hiding and
providing interfaces or accessor functions to the data attributes.
Direct access to data by any client, bypassing the interfaces, goes
against the principles of encapsulation, but the programmer is free to
allow such access. As part of the implementation, the client should
not even know how the data attributes are architected within the
abstraction. In Python, all class attributes are public but names may
be "mangled" to discourage unauthorized access, but otherwise not
prevented. It is up to the designer to provide the appropriate
interfaces to the data so that the client programmer does not have to
resort to manipulating the encapsulated data attributes."