@Leftsaidtim I either disagree, or don't fully understand the boggle there.
In the first example, I wonder why you'd have a `__size` or `size()` in the first place, and not just add them into `__len__`. That seems like it'd be the more Pythonic approach.
```
class Set:
def __init__(self):
self.__values = []
self.__size = 0
def __len__(self):
return self.__size
def add(self, value):
if value in self.__values:
return
self.__size += 1
self.__values.append(value)
```
```
def test_size():
empty = Set()
has_stuff = Set()
has_stuff.add("waffles")
has_stuff.add("cheese")
assert len(empty) == 0
assert len(has_stuff) == 2
```
@diji Ah that's a good point. I should have pointed out that I was considering this as an exercise of defining our own interface, separate from knowing anything about len(), or other python built-ins.
It's a bit of a strawman argument as a result, but there's certainly other cases where you're building your own interface and it's tempting to expose a variable directly, rather than a method.
@Leftsaidtim That's fair. The problem with exposing the field directly, is that you have no control over someone mucking with it. If a field expects a string, and methods in the class hinge on it being a string, then someone replacing that value with an int or None could be bad.
That said, the ethos of Python is "we're all consenting adults here".
You can do getters and setters with the property decorator, which does allow you a measure of control. This is a bit anti-pattern though.
@Leftsaidtim This link covers that:
https://realpython.com/python-getter-setter/
You're not wrong though. We're giving the kids access to matches and hoping they don't burn down the house! :)
In this tutorial, you'll learn what getter and setter methods are, how Python properties are preferred over getters and setters when dealing with attribute access and mutation, and when to use getter and setter methods instead of properties in Python.
Leftsaidtim
Josh Schneider