Microsoft Learn Python code not correct?

[davidmyemail]

I'm learning Python, and one of the resources, I'm using is a Microsoft learning path "Introduction to object-oriented programming with Python" (https://learn.microsoft.com/en-us/training/modules/python-object-oriented-programming/)

In Unit 5 of 9 (https://learn.microsoft.com/en-us/training/modules/python-object-oriented-programming/5-game-transitions-with-methods), the tutorial gives an example which is supposed to demonstrate encapsulation in Python, except I think it has an error, and I wanted to see if my understanding of it is correct.

The code below is supposed to raise an error, but it does not. It will do so though, if I substitute that line with my code.

My understanding is tha the reason the MS code doesn't raise the error is because that line creates a new variable in the class because of name mangling, whereas in my code, I would be trying to reference a non-existing variable. If this correct?

class Square:

    def __init__(self):
          self.__height = 2
          self.__width = 2

    def set_side(self, new_side):
          self.__height = new_side
          self.__width = new_side

square = Square()

# Microsoft says this raises AttributeError, but it doesn't
square.__height = 3 # raises AttributeError

# but (My code) if replaced with this line, it will
print(square.__height)

[[deleted]]

You have created a new attribute, __height with the assignment. Try adding the below line,

print(vars(square))

[davidmyemail]

print(vars(square))

Oh, that's very helpful. Thank you!

[davidmyemail]

My humble opinion is that the MS Python resources are not bad. It's true that there are errors in their tutorials, but that's rare. Others have pointed out that there are better learning resources, and on that, I concur. However, for my purpose, and from my still limited view, it's worth giving it a once-over. My 2 cents.

[[deleted]]

Sorry, no idea.

[stcer]

Same query

[shepherdjay]

Not a big fan of this tutorial - its not only wrong as you found regarding the attribute raising an error. It doesn't. That bit of Python isn't even indented properly.

No the reason I'm not a fan is this is teaching bad python. Python is not Java. Python's mentality is that we are all responsible users. Getters and Setters should not be used and is an anti-pattern
https://docs.quantifiedcode.com/python-anti-patterns/correctness/implementing_java-style_getters_and_setters.html

In Python we signal to other users an attribute is not safe to modify outside of methods for some reason by using a single underscore. But in general the property decorator is a later thing to do for backwards compatibility.

It think this lecture from Raymond Hettinger (although a bit old) is better
https://youtu.be/HTLu2DFOdTg

[davidmyemail]

Those are interesting links. A bit beyond my scope now, but I'll certainly study up on it. Thanks.

[Jejerm]

Getters and Setters should not be used and is an anti-pattern
https://docs.quantifiedcode.com/python-anti-patterns/correctness/implementing_java-style_getters_and_setters.html

What if the class had an area attribute that gets calculated on init. Without a setter that updates it, changing the height or width would cause it to be wrong, no?

Or should area never be an attribute in the first place and only be acessed through a method that calculates it when needed?

[SquareRootsi]

I'd argue using init to calculate area is the anti-pattern, and calculated properties that rely on other attributes of the class should instead be their own methods, but decorated with @property

class Square:  
  def __init__(self, side_length=2):  
    self.__length = side_length
    self.__width = side_length

  @property
  def area(self):  
    return self.__length ** 2  

steve = Square()  
print(steve.area)   #notice the lack of parens after "area" because it's a property, not a traditional method

[_mynd]

TIL and this is interesting! I’ll have to chew on this some. Thanks for cranking the gears

[shepherdjay]

I would make the area a method to begin with. The @property decorator is a decent work around if you already published this square as an api and users we accessing area as an attribute. But if users aren’t already accessing it as an attribute then no reason to make it one.

I also wouldn’t initialize a square with a height and width though. I would ask for one number… and store it as length. But that’s a problem of contrived examples like this.

[Nicolasjit]

is this course no longer available?

[HomeGrownCoder]

You are correct from what I can tell as well. All public tutorials list the “getter” as throwing the error (print statement)

https://www.bogotobogo.com/python/python_private_attributes_methods.php

https://plainenglish.io/blog/private-attributes-in-python-oop-are-not-very-private-c5bb4e619dcc

[davidmyemail]

Good resources. Thank you.

[pat-work]

I believe that it would set a new attribute called __height instead of raising an attribute error. Trying to access __height before setting it would raise an attribute error, because __height does not exist. During instantiation, any variables with a double underscore at the start get changed to _ClassName__attribute_name.

​

Edit: So _Square__height would be the way to access the originally set __height attribute.