@@karunesh26march __baz is name mangled, so it can only be used inside the class that defined it, not its derivatives. This is what private means in C++. _bar is not mangled, so it may be used elsewhere.
... and if you want to impress your friends, there are also underscores in int values which arguably improve readability, but are ignored by Python. Eg: x = 1_000_000 gives us the integer-type variable x and its value 1000000. x=1_2 gives x the value of 12. x=1,000,000 creates tuple (1,0,0), btw.
To elaborate on this explanation, avoiding name conflicts is the most important and missable use of the double underscore variable and function names. When a class is inherited from, any methods that the base class uses in its methods are searched for in the current scope (the new class). Therefore, if a method from the base class has been overwritten, the methods that call that method will call the new method instead of the old one, breaking the class. The double underscore system was implemented to fix this. For a crude example in python 3.6: class Temp: def get_temp() return "274 Kelvin" __get_temp = get_temp def display_temp(self): print(self.get_temp()) def display_temp2(self): print(self.__get_temp()) class Fahrenheit(Temp): def __init__(self): self.display_temp() # will display the current temperature in Fahrenheit now self.display_temp2() # will display the current temperature in Kelvin def get_temp(self): return "33.5 degrees Fahrenheit" As for making variables private, python tries to push user away from doing this. As Dan states, the underscores are mainly hints to other programmers. The @property decorator was implemented to this end.
00:21 here is the constructor of the class (생성자) 00:46 _ : underscore (single underscore) is to be treated as private by the programmer (private variable, so careful about changing), 파이썬은 public과 private 차이가 크지 않다. java에 비해 __ : dunder (double underscore) 4:13 t.Test__baz Thank you
Hey, you're getting a rendering bug with the characters in your comment, I saw a vid on that one, never thought I'd see it myself. The engine rendering RU-vid is reading the Unicode characters as utf-16, which are 16 bit characters. The bug comes from how the browser engine reads the endianness of utf-16: little-endian or big-endian. If it can't read the big-endian characters correctly it'll frame-shift and read the chars in the wrong bit order, as little-endian, rendering Chinese characters rather than English letters. Windows had a problem with this for a while
single underscore usually means private variable, double (dunder) means new classes will use the name mangling correctly with variables with same name dir() returns attributes
Hi,Sir Dan.JV here again.Your video is really nice and I could understand everything,sir.I have view this video,like this video and subscribed the channel,sir.
The explaination of dunder __baz doesnt make sense to me as a new developer ; for the same reason it could mangle the other 2 instance variables too (_bar or foo). Just the reason could be because the __ dunder has special meaning in python as its used for constructors & builtin language methods by convention it avoids the user defined names by name mangling
Possibly you can just unit test the "public/protected" methods, because the inner workings of your class will be revealed to be faulty if the outer facing thing that calls them fails
It a nice explanation... but it raises another question now: what happens when inheriting from the class and defining new variables foo and _bar? wouldn't that causes naming conflicts and confusions too?
Yes, and that's the intent. You want foo to be publicly accessible, _bar be used in derived classes, and __baz to be available exclusively to one class.
Thanks for this, had a dual initiation bug where my configuration class was loaded twice when only calling the class once. seems this was a name mangeling issue.
I would've loved to see what happens when you extend your Test class. Like would there be _Test__baz AND _extendedTest__baz or just the latter? I guess I'll have to go do it myself...
Clear explanation of how Python is not object oriented. Does this still apply in Python 3.6? I know a lot of things changed. Wondering if this is one of them.
Hi, Dan...Congratulations for your great job... Would you like to tell us what is your opinion about the few protection of the attributes (in objects) in python in comparation with Java? Do you think that this characteristic can be considered a defect of python?
_bar wont allow import * to itself ... not sure if it should be called protected . Even that can be bypassed by putting __all__=['_bar'] in the above code
Ya, missed that a bit too. But there are comments explaining it. For example you may have a new class enhiring from the original one and defining a method which has a name already defined in the original class. In this case the new defined method will overwrite the one with same name from the original class. This may break the functionality of the original class enhireted unintentionally. To prevent that __ results in name mangeling preventing this Inbus.
I have a quick question. If the given variable is 'Total Sale' when transformed into an underscore writing should it be written like this 'Total_Sale' or 'total_sale' or even 'Total_sale'? Which one's correct?
Nice video !! one doubt I have.. I heard in the video you said the one with a single underscore is private variable ? is that true? I believe the one with a single underscore is protected variable and the one with the double underscore is private.. please correct me if I am wrong.
I've found they are best used with the @property decorator, to prevent people from setting the variable when I only want to allow getting. class T(): def __init__(self): self._foo = 0 @property def foo(self): return self._foo t = T() t.foo -> 0 t.foo = 1 -> AttributeError: can't set attribute @property decorators can be used to do a lot more stuff but this was the basic explanation that opened the doors for me initially.
Thanks great video. Honestly python is a language with some really bad designs. The using _ instead of declaring the scope just leads to more difficult code to read and i really don't understand, why they thougt it was a good idea to use white space for scoping the code.
How are we able to access magic methods normally then? Are they not name mangled? That is, "Hello".__len__() "Hello"._str__len__() The first one works fine despite being a private method. The second I never tried.
You should access __baz only inside its class. Use it for internal helping methods or attributes, that are not part of the public interface, and must not be altered/overridden through inheritance.
You did not show how to access the dunder bazz __baz within the class. Do you use the class name, then dot notation to get to __baz? Example: Test.__baz >>> 42 Is this how to get the 42?
