Every Python dev falls for this (name mangling)

This video seems like you rage quite a project and just had to vent in the most productive way possible

Why did the python's designers decide to choose the name mangling rules they set? I'm not smart enough to see what benefits they have and what problems they remove. I never liked the double underscore in python aesthetically, it looked like someone just tried to mess with the readability and confuse the observer. Same with selfs everywhere. I might be too dull to use python, but the biggest difficulty for me was that despite it supposedly being more like telling the computer in human language what you want to do, it caused me a lot of difficulties because I didn't understand the rules of how it works and should be used when it looked like it didn't care for rules too much. Like when I tried to speak to it, it actually didn't understand what I wanted. And it still required me to put this thing here and that there, but it just looked like it was careless. The strictness of c++ brought comfort in "these are all the hints that what you're seeing is this and what you're doing is this. you better put the ; there and {} there and painstakingly defining and syntaxing things and explaining the computer step by step what you want to happen".

I love python, but I can’t shake the feeling that it tends to be the wrong choice for any kind of large project. It just doesn’t have the same scope of tools to manage complexity when compared to languages like Java and c sharp.

I've seen some JavaScript code that was using IIFEs to create an exported object containing any functions and classes you would like to expose. And for some object attributes it was mangling them with a random string created when the IIFE was running.

oh my god I cant

Name mangling is fine. The rules aren't complicated. They can be presented in a much simpler and clearer way than in this video. Nothing confusing about them.[1]

Name mangling is useful. Let's say I write an open-source library, and thousands of people use it and extend some of its classes. Without name mangling, I could never safely add a private property to one of these classes, because there may be sub-classes out there that already use the name of my new property. With name mangling, I can safely add any private property I want.

[1] Well, very little is confusing. Of course, mangled module names don't make sense, but that's a purely theoretical problem.

The most common place to enounter this was when learning to use the `threading` module. It used "dunder" properties for its internal storage in python2, and I think early python 3 (before 3.5).

That said, a single underscore is more akin to "protected" from languages with explicit access controls. It means something isn't part of the public API, but accessing (or even writing to) it may be fine if you are subclassing to extend its functionality.

Double underscore is private , same way that private stuff is in C++. Yes, you can redefine the struct and reinterpret cast in order to access those private fields, but the compiler has gone out of its way to encourage you to not .

Of course, this is largely no longer needed, as modern IDEs will warn you if you are overriding something from higher up the mro. I got my start about 20 years ago, using bare `nano` ; having dunder variables was fairly common, and we were glad to know not to mess with them. I do still use them fairly regularly though, for things I don't want messed with. Because it's done at compile time, there's no performance impact, and I really don't care if someone gets confused when `getattr(foo, "__bar")` doesn't do what they expect. If it breaks when you mess with non-public APIs, you get to keep the pieces.

Btw, in C++ we have a best practice to name different class members and methods in a specific way:

* When declaring private method:
_ + myPrivateMethod()

*When declaring a private member (variable): m_ + myMemberName

*When declaring a public member:
think twice, and declare the member itself as private and provide an API to access it (getter and setter)

use properties for getters and setters:

class A:
__count = 42
@property
def count(self):
return self.__count

@count.setter
def count(self, value):
self.__count = value


Now if you repeat that code in sub class:

class B(A):

__count = -999
@property
def count(self):
[etcetera]

then:
.>>> a, b = A(), B()
>>> a.count, b.count
42, -999

each class has a truly private unmangled count read/write public attribute that don't collide.

I have been learning and using Python for 4+ years. And even teaching an intro class a few times.

And I run into new issues all the time. Right now I struggle with relative imports just because I wanted to be fancy and skip copying code. Two days later I was forced to figure out packaging and refactored a lot of the script I had to now have a module of utils. Feels good, but I still haven't solve my initial issues of reusing a complex function elsewhere. Can't import that anymore because it imports the relative utils package now -.-

My brain is now positively mangled after watching this.

In general, the dynamic features of Python should be avoided out of respect for their power and used very judiciously. There are indeed some scenarios in which they are useful, but doing things the static way is always safer.

Damn, thank god I don't use underscores in my variables too much

Damn I knew about this and thought it probably makes sense as a middle ground between true private and no safeguarding at all, but never realized how many rough edges it has...

This is one of the many reasons why I tend to avoid OOP at all reasonable cost

I think It would be cool use private property instead of singleton pattern

As I used to know in earlier versions of python when you tries to reassign any strictly private property in a class you will get the error!

what an absolute dumpster fire 😭 let's just all agree to pretend this "feature" doesn't exist

I discovered it last year in an article written by Dan Bader, and I didn't even think about someone trying to change the attribute using the "wrong" name.

How about writing a custom _getattr__/__setattr_ on your class that would check if its not modified from outside of the owner class to know there is an issue early?

I thought the problem was it being a class field instead of an instance member.. Do you not need a constructor? maybe I don't know enough python

The main thing name-mangling is legitimately used to avoid name collisions in code that needs to be able to subclass arbitrary types or otherwise inject some sort of extra management attribute into an object of an unknown type.

One more reason to choose functions over classes whenever possible 😀

Trivial setters and getters are a waste of time, to begin with. Replicating the power of the "=" operator is an idiocy that should be punished by the law. Trying to enforce private variables in a dynamic language is also completely braindead, both by the language developers and the language user. OOP and dynamic languages simply don't mix.

You should not have called it 'private name-mangling', because it is just 'name mangling'. Adding 'private' is not only incorrect, but also adds to the confusion that it has anything to do with private variables (which isnt the case).

I want a refund

I feel like a deep understanding of this would prevent tens of hours of struggling. But I know I’m going to have to learn this the hard way

Good video!!

Thank you for explaining something that makes -0 sense.

"python dev" is a joke in itself

I think the lesson to learn here is that inheriting state in a non-controlled type hierarchy is something to try to avoid.

This applies to OOP languages in general, not just Python.
With Python having an extra reason for why, this lack of sane way of namespacing member variables across inheritance.

My first thought was "why is he using double underscore for a variable name? Where did he pick up that strange habit? And: Dunderscore has meaning in Python, you don't do that unless you know what you're doing, in which case: why is this a problem?

Anyway: All this is just more reason to NEVER EVER access an class' internal variable directly.
The other reasons ofcourse being that manually getting or setting an internal variable bypasses all validation of that value so you're literally creating a bug, and that you use classes specifically because you don't want the outside code to be coupled to your code in any other way than the interface you provide for the class.(And yes ofcourse it can be convenient to just access it directly and yes "we are all adults here", and the "one underscore means don't touch" is a nice gimmick, but you go ahead and deploy that strategy for a few years and tell me how it goes as developers come and go in your company and code gets forgotten about and updated and fixed and mutated. It doesn't go well)

And yes, this means I have never fallen for this problem. Stop clickbaiting your titles.

Whats confusing in your example is that you use __count as an instance variable but also initialize in as an class variable on A.__count = 0
tldr. the line after class A: should not be there

Python is the worst.

Before I saw this video: If you want to use private variables, do it in C++, not Python.
After I saw this video: If you want to use classes, do it in C++, not Python.

What a POS language.

After working with a strict language, it's incredibly hard to understand how Python works in many cases.

I'm currently studying Python after having learned C++ and Java and I absolutely hate it.
Like, fine, dictionaries and tuples are nice, but shit like mangling and lack of type declaration is just not worth it. And the syntax isn't all that cleaner or simpler in my eyes... Sure it's easier for complete newbies to stare at, but it's not at all more self-explanatory so trying to read someone else's code is harder than Java for example, and if you actually work with code you're probably going to read other people's code far more often than have to explain the code to a non-coder.

Besides python just translates itself into C or Java anyway so why bother, I could just as easily write in Java and be done with it.

If they ever make python 4 i hope to god this gets dumped

You really shouldn't be mixing ststic class variables and instanced variables like that anyways. Assign the variable in the constructor

Glad I didn't use __ ever. To me it strengthens me in thinking Python is crap. Everything they don't have and other languages have, they try to do something for it, and it ends up in a mess.

python is held together with ducttape...

...so just don't use Python. Got it

To be fair in other languages nefarious authors can still access private fields via reflection (java), memory transmutation (rust), etc.

Python is a piece of crap. All those _init__, __get, __dict_ and others are awful. Spaces matter -> awful, good luck with merging and refactoring bugs.

You can use single _ and @properpty for you getter, @varname.setter for setter.