Every Python dev falls for this (name mangling) 

The point isn't to provide private variables, but to prevent name collision in subclasses.

@@aantoniou96 Not true. Read the docs. "it can be used to define class-private instance and class variables"

@@SeanBracks Although the documentation does describe name mangling for creating "class private variables", it's not "private" in the conventional sense that it prevents users from accessing those attributes. The same explanation is also given by the doc's tutorial at section 9.6. "Private Variables", pointing out that the feature is only there for the use of collision avoidance. (yes, their terminology for this subject is all sorts of mixed up)

I had to extend some code that was written entirely like this and it was a nightmare. I ended up rewriting it in a new language. It's so infuriating, python is meant to be open and extensible and writing like this is like you're trying to write in C++, it really makes it worse

@@aantoniou96 And yet, it doesn't even achieve that, because you can re-use class names between modules further down the inheritance hierarchy. Not to even that it *is* used as a "soft" way of doing private variables in practice, because the two concepts are not a million miles apart.

m_ for member.

@@0neMadGypsy Thats the problem in Python. it doesnt have any way to declare some var as protected. and private doesnt really exist either, because you can use _classname__var to access __var. Its just convention to not mess with attributes (or methods for that matter) that start with an underscore. there is nothing stopping anybody from accessing those "private" attributes. while this seems kinda weird, its kinda nice to have this ability in a scripting language, which python is, because sometimes you want to manipulate some data without using the methods the library gives you and you dont want to do it the right way (which is probably to compile the library yourself with public attributes), because you just want a quick script to do some job, not some high quality solution that will stand the test of time until the universe burns out

you can use _classname_var to access members of an inherited class. This helps solving some of the puzzles you'll inevitably come up with when trying to solve the obvious resolution order problem arising from multiple inheritance. In fact, this actually makes dunder variables VERY useful given the adecuate context. Note that this context is NEVER publicly accessing members not designed for it.

@@0neMadGypsy yeah what this^ guy just wrote

php had __construct class methods builtin as default and the such built in to the oop part,whenever you defined some var with a new class too, you would EXPLICITLY name them so they would get called lol using those __ because they used to be like that in php and java is just a convention thing people took with them i guess personally i wouldn't touch python with a 10 foot pole if i didn't have to languaged with forced indenting are retarded. i don't trust languages that don't use semicolons as line enders, the entire basic-like structure falls flat if it means having to import C libraries for performance lol

No Guido chose it because he liked Monty Python's Flying Circus

​@@vectoralphaSec 😑

Yes, this is the official, or conscious, explanation :) He could have chosen 'Parrot' (I know, Parrot is now occupied) or 'Monty'.

@@vectoralphaSec ...and: nerds love monty python, therefore: python is built for nerds. (Which is good in a computer language. You know what is NOT built for nerds? Microsoft office. 'nuf said.)

Except if you're always using these variables as if they're ACTUALLY private, none of these implications matter. Use them in a sensical way, and you won't ever have an issue.

@@CrapE_DM if anyone else subclasses your class, you have to hope that they know to follow the rules. Otherwise you have left a hidden mine for them to step on. From personal experience, assuming outside users understand things like this is not a good assumption.

it's like metaclass....you may never need it, but if you do: you'll know how to use it by then.

Hey sexy, how are ya.

Thank you as always 😀

What about containers. Functional languages usually have copy-on-write optimizations for modifying them. In python you would need to shallow-copy any data structure (dict, list) when you add or remove anything, killing the performance. How do you get around this?

BTW I find this very interesting, as I also see the huge benefits of such approaches.

Yeah, I like that approach, too. I write a lot of data mangling code, which can get complicated really fast.

I'm a bit fuzzy on the details, but don't frozen dataclasses effectively enforce private variables?

Frozen doesn't make the meners private. It makes them read only. SO once an object is constructed it is immutable. The same as tuples behave.

99 times out of 100 if you reach for the word "class" in python (and you're not using it just like a struct), you're likely doing something wrong. The language just wasn't built for proper OO support so if you're not building a general-purpose library type like pandas dataframe, the whole thing is best avoided.

I'm sure everything will be fixed in Python 4.0 🙃

@@mCoding I dont think so. At least not from how Guido described Python 4.0 when he was on Lex Fridman podcast.

type hint let the wrong people in.

May your career rest in peace lol. Just kidding, now you know, get back up and try again!

Any interview that tests you on that is absolutely stupid. Interviews should not try to trick you or test whether you know some inane detail such as this, because it has no bearing on how competent you are as a developer.

@@davepruitt agreed. but it was just one question. there were more. other questions weren't that bad.🥺

Well, if you have a variable that you don't want the user to have access too, I think making it private would be a usecase for doing so. The point of making somethng private is to make it more explicit that the variable can't be changed outside of it's scope.

Same; almost never needed it in 12years of using Python. Beginners should avoid this topic completely, simply because they don't need it.

@@steven7936 but that concept does not exist in Python; there is no 'private' and there is no way to prevent access (and there is no reason to do so anyway).

Ive used it where I had euclidean a vector class, and then needed a Gibbs version (complex values for quantum angular momentum)...so with mangling I was able to add a few lines do decide if abs() -> sum(getattr(j, self)**2 for j in 'xyz') or if getattr(j, self)*getattr(j, self).conjugate() was required. very slick.

By clicking the video you have fallen for the trap, as advertised. It follows that the title was accurate. Maybe I should put something about mangling in there just so it is more searchable....

changing instance attributes outside its own instance methods is a sin.

This is the most Python thing I've ever heard. You should know how your classes are supposed to be used (I mean, you designed and wrote them...), and should structure them such that they can only be used in valid ways - or at least such that it's difficult and obvious when you're using them in an unintended way.

Thanks so much!

Real privacy is unpythonic because it's assumed that the programmer isn't trying to fuck themselves over intentionally. Getting/setting an _varname is basically telling the library that you think you know what you're doing, and if you really want to shoot yourself in the foot, then that's your right.

no, people should just learn the language instead of trying to copy Java. Why would you make something 'private' anyway? in some languages it makes sense, but not in Python: name conflicts are extremely rare in Python because it has Modules. instead of using getters/setters every real Python dev uses @property or writes custom descriptors. Learn to use the __set__ special method.

It would seem so but keep in mind they are "kept" under their respective class anyway

I don't think they expose the official function, though you can feel free to copy the one from this video (and maybe optimize it a bit). I wrote it by going line by line though what the CPython implementation does and translating it to pure Python.

You've got the right idea about the linter rule. As for why it only works if your classes are statically typed, if your classes are not statically typed, how does the linter know what the variables in your class or any of its parents are? If it doesn't know what they are, it can't warn you if there is an overlap. Keep in mind the linter does not run at runtime, so it cannot simply inspect the object in question. Instead, it operates on the source code, typically by computing the AST or CST and checking based off of that.

@@mCoding i still don't understand the problem. lets pretend someone implements a class ClassA which initializes a variable _counter to 0 on all of its instances. if i make a class ClassB that inherits from ClassA, and i initialize _counter as an empty list on all of my ClassB instances, shouldn't this be as much of a visible problem as if i initialized _counter as 100,000 on all of my ClassB instances? regardless of whether my linter can tell what type _counter is supposed to be, it should be able to see that it is being assigned in ClassA and overridden in ClassB, yeah? i must admit i don't know much about linters, so its possible i might just not have the background to understand the problem, but i think its equally possible i might just be misunderstanding the situation to begin with lol

Indeed, for a private variable people outside of the class should not attempt to use it or modify it except through mechanisms the author provided. Because python is so dynamic and this feature is so unexpected, people often run into it on accident anyway. E.g. someone writing a subclass may try to modify the variable directly.

You better see a __private practitioner!

Indeed it can be made more horrendous using slots, you end up with mangled slot names. I dare not post such cursed dark magic in the clear web.

@@mCoding I've also just seen someone combining it with slots and metaclasses and... wow. Just wow. So hurried to see if they could, they never stopped to ask if they should.

If you TREAT them as private variables, you don't have to worry about any of the [seemingly] weird behaviors. (Other than how it mangles strange class names)

Just use a single underscore.

It obviously prevents suckers like James to access the “private” variable so I call this feature a huge win.

pseudo

Monokai Pro! Idk why it's called "Pro" it's not a paid thing. I did make an adjustment or two (looking at you, dark purple) to make certain colors more video friendly.

@@mCoding thank you so much!!!

You're right that class fields can also cause beginners confusion, though I did that here just to make the thumbnail less cluttered. Perhaps I should update it... Anyway, to answer your question, no you don't need to define a constructor because the base class object has a default one that does nothing, although in most classes you would typically want to do more than nothing.

Can you even do class Animal(Animal): ...?

Although it is certainly bad practice, Python will not stop you from creating two classes with the same name even if one inherits from the other. In this case, even mangled names will clobber each other. Think of it like a punishment for a bad decision. (Unless you didn't know some parent of a parent had the same name, in that case you just got blindsided).

class Widget(module.Widget): # ouch

If you inherit from a class and you name the daughter class like the mother class, that is completely on you, my man. Do not complain about hammer's functionality just because you keep hitting your fingers on purpose.

One should NEVER put state in a class to begin with. State is a singleton. There can be only one. Classes are the antithesis of singleton objects. Data can be in classes (where it is also usually misplaced), but state... never.

@@lepidoptera9337 I'm a little confused as to how you are using "state" and "data" in you comment. What I was referring to as "state" is mutable state stored within the instance, like mutable instance variables. When you say "data", do you mean like immutable (or read-only) stuff in the instance?

@@TechSY730 State is the persistent information that controls a program's primary function. Think about protocols between two communicating programs. If the sender requests a transmission, the receiver either has to guarantee reception by design and acknowledge that the data has been received (possibly even with a check sum mechanism) or flag a transmission error. What data is being transmitted is completely irrelevant to the protocol. The relevant state variables are only controlling that the transmission was valid. In a simple protocol that might be half a dozen binary flags, even if a GByte of data is flowing per second. A user interface of a program meant to be used by humans is, in this sense, also a protocol. The user expects that certain inputs produce reliable actions inside the program and he expects feedback about the progress of those actions. Whatever variables are being used to assure that, that is "state". If I click on "Save", I expect the program to save my data, no matter what is in that data. I expect some kind of confirmation that my data has been saved, even if it is subtle. If this doesn't happen, then there will be an extremely unhappy, insecure user. I had to work with programs that did none of that. I won't name names, but it was hell. So, yeah, the meaning of "state" here is NOT the entire content of your memory. State is what is really important and what can only exist once because the "user" only exists once. And this problem isn't just "external" to a program. It is also internal to the way classes communicate with each other. And this is where the problem begins to grow to epic proportions: how do you make sure that state is immutable if anybody can call a state changing member function? Yes, your "state variable" in an object may be local, but your call graph to the member function of that class isn't. Anybody can change your state, anywhere, any time and there is nothing in the syntax of a typical OOP language to prevent that from happening. OOP therefor gives this false sense of security, when in reality the atomizing of state across multiple classes makes it nearly impossible to track the actual state changes without constant analysis of the call graph.

You can, just be aware of the tradeoffs and then you won't be surprised by any of this mangling

yes. it is actually very good.

I wonder if chatgpt knows about mangling 🤔

@@mCoding It does :) I asked it myself. It also clarfied the _ notation as well which I didn't know was a thing.

it is not meant for private/public ; these concepts do not exist in Python. double-underscore is only to avoid name conflicts in some situations where classes are inherited and happen to have the same variable-names.