conceptual problem (was: A beginning beginner's question about input, output and . . .

[Cameron Simpson]

On 13Jan2021 10:37, songbird <songbird at anthive.com> wrote:
>  my momentary conceptual problem is that to me OOP means
>being able to encapsulate data structures and code from
>other parts of the program, but to me it doesn't look like
>that is how python is designed.  this is probably a complete
>aside to this whole thread and perhaps even this newsgroup
>so i'll subthread this.

Python allows you to avoid mucking with the object internals from 
outside. But it doesn't prevent it.

So you can (and often should) adopt an OOP approach - it reduces the 
dependencies between your classes, with the benefits that brings.

The "pure" OOP approach, where method calls are used as messages to set 
or fetch aspects of the object, is usually does with getter and setter 
methods like:

    x = o.getX()
    o.setX(9)

In Python this is less common. Simple things like that which do not 
intrude much on the conceptual model (i.e. if all such things will have 
an "X") are usually exposed as a public attribute which you can get or 
set directly:

    x = o.x
    o.x = 9

"Public" attributes in Python are just a convention: we name "private" 
attributes with a leading underscore and "public" attributes with 
leading letters and expect people using our classes to behave well.

Sometime we _don't_ have a plain old attribute "x", but we do have a 
property of the object looking like it. Then you can implement something 
which looks like an attribute from outside:

    @property
    def x(self):
        # "x" if a derived value
        return self._a + self._b

    @x.setter
    def x(self, new_x):
        # setting "x" gets split between _a and _b
        x2 = x / 3
        self._a = x2        # put some in _a
        self._b = x - x2    # put the rest in _b

    # you can still do this, but it calls methods now
    x = o.x
    o.x = 9

So Python supports OOP practices but doesn't enforce them. Adopt the 
degree of discipline you think best.

Cheers,
Cameron Simpson <cs at cskk.id.au>