On 13Jan2021 10:37, songbird <songb...@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 <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
