Every Python dev falls for this (name mangling)
Don't fall for it!
The Zen of Python must not have been invented yet because this feature is confusing, not obvious, implicit, and much more. Private name mangling in Python converts variable usages like __var into _ClassName__var at compile time and there's no warning it's happening until you run into the trap.
― mCoding with James Murphy (mcoding.io)
Source code: github.com/mCodingLLC/VideosS...
Python docs: docs.python.org/3/tutorial/cl...
CPython mangle: github.com/python/cpython/blo...
SUPPORT ME ⭐
---------------------------------------------------
Sign up on Patreon to get your donor role and early access to videos!
/ mcoding
Feeling generous but don't have a Patreon? Donate via PayPal! (No sign up needed.)
www.paypal.com/donate/?hosted...
Want to donate crypto? Check out the rest of my supported donations on my website!
mcoding.io/donate
Top patrons and donors: Jameson, Laura M, Dragos C, Vahnekie, Neel R, Matt R, Johan A, Casey G, Mark M, Mutual Information
BE ACTIVE IN MY COMMUNITY 😄
---------------------------------------------------
Discord: / discord
Github: github.com/mCodingLLC/
Reddit: / mcoding
Facebook: / james.mcoding
CHAPTERS
---------------------------------------------------
0:00 Unexpected output
2:31 Private name mangling
4:23 Python does not have private variables
4:54 Mangling rules
6:51 Mangling at compile time
8:28 Compiler explorer
10:18 getattr and setattr
10:55 To mangle or not to mangle?
13:53 Thanks
Wow. I knew about name-mangling, but it's even worse than I expected. Maybe it has valid uses, but it definitely feels like a half-assed implementation of private variables that opens up far more traps than it solves.
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.
You make top tier videos showcasing advanced Python topics. There is just too much beginner videos lying around. Therefore I'm glad to feel challenged by watching your videos
I finally understand why they chose ‘Python’ for the name of the language! It wraps itself around your brain and squeezes all the sense out of you! :)
No Guido chose it because he liked Monty Python's Flying Circus
@@vectoralphaAI 😑
Yes, this is the official, or conscious, explanation :) He could have chosen 'Parrot' (I know, Parrot is now occupied) or 'Monty'.
I remember learning about name mangling in my Intro to OOP class and we all just wished that we didn't have a question about that on the test. It's something that our lecturer told us to try and avoid and just use the convention of "underscore at the start means private - do not touch". Anyways, another informative and entertaining video from you :D
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
I stopped at 1 minute. This name mangling bit is there to provide private variables. Python doesn't strictly enforce private variables, but I use a convention where one underscore means it's internal and you shouldn't use it, but it's readily available just in case. But seriously, I'm a Python developer who's never had this issue.
I was aware of the initial quirks, but didn't expect it to have so many implications. Thanks for this video; you saved future me a bunch of time.
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.
I have definitely encountered this issue before and I am blown away by how much more complicated and weird the behavior is than I realized. My general approach has been to just avoid using the "feature".
6:26 - this is golden, you've really managed to capture and portray everyones feelings in 3 seconds
Least clickbait title ever, A+
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....
I knew about name-mangling, but I clicked on this video knowing I'd still learn something new. Had no clue about the mangling rules and was also happy you briefly showed the C code, which I was curious about!
This is one of the many reasons why I tend to avoid OOP at all reasonable cost
great vid as always, was fun to watch with the editing 🤩 also loved the Star Wars references
Hey sexy, how are ya.
Thank you as always 😀
I have avoided these headaches by never using double underscore prefixes.. Im likely to keep that habit.. I get the sense that as Python blew up, it’s gotten pressure to have features of other lower level languages.. static typing and private/public attributes. But b/c those were afterthoughts and the solutions were retrofits, we get these wonky implementations.
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.
Thank you so much. I've spent half a day once trying to figure out what the hell is going on when one of the classes used different implementations of one of the functions depending on the conditions (self.__run_command = run_command_locally if local_machine else run_command_via_ssh). It was quite hellish exercise, until I found it out in a hard way. Switched to single underscore.
Lately, due to many issues like these, I've been borrowing a lot of principles from functional, while still essentially using OO. For one, I try to make stuff immutable with named tuples or frozen dataclasses. Then I try to think of classes more in terms of types and its variables as defining its uniqueness. If something changes, it's a different instance of that type, so no counters. I've found that most of the time, moving counters out of classes makes for more readable, flexible, and loosely coupled code anyway. And if you learn how to leverage comprehensions, map, any, all, sum, itertools, etc., you often don't need counters. For things like widgets, use the ol' "composition over inheritance" mantra. You don't worry about stepping on any component's toes if you have to access them by their instance name anyway.
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.
I've been writing python since 2010, and consider myself a bit of a python expert. I've used name mangling in production... a whopping zero times. I've seen it in libraries only a handful of times. I've used it while messing around and found it kind of useless as long as you follow good hygiene. The answer to the question "how to avoid clobbering implementation details" is indeed look at the source code. Python is so heavily dynamic that if you feel the need to use _underscore attributes in a subclass, you really do need to know what the parent class is doing.
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.
I love that for every rule you introduce, you sound increasingly embarrassed that they exist
The funny thing is I fell for that in the worst place possible. In my interview.
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.🥺
Or an even better solution: do not use inheritance from classes that are not interfaces (and thus don't have private fields) at all, and instead use composition, that is better in many ways. Avoid the problem completely basically.
"Well, let me introduce you to the questionable feature behind all of this confusion: classes"
I learned this a long time ago when I went deeper into the language syntax and semantics. If I use either _ or __ then it's because i dont want the property to be accessed directly outside of the class. The key things I learned were to bind it to the class in the constructor and learn how to intuit whether it should be used it or not. I only use getters and setters in certain circumstances, but if i expect the property to be accessed outside of the class, then there is no point in using either _ or __ and I completely drop the @property decorator. Personally, I abide by always binding properties to the class. I see no rationale for placing it outside of the constructor for the very reasons mentioned in this video. Regardless, this is A+ material and I enjoyed the deep dive as it was a refresher for something I learned years ago.
changing instance attributes outside its own instance methods is a sin.
You just flipped my world and I'm surprised I never ran into this issue before. Must be because I rarely ever use classes.
easy to avoid - don't use double underscores on class variable names if you plan to use them outside of the class.
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.
Great vid. Will say you missed a potential solution where you prefix the variables with a namespace like in C or ObjC. It’s not great and you do that in those languages of necessity, but it does solve the problem better IMO then manually pre mangling and you don’t have to follow the weird rules of that. Now it’s a bit hair splitting cause depending on how you namespace it’s the same _Class_Var is the same as just mangling but _Module_Class_Var or _pClass_Var is a technically not. It is still not a great solution considering Python is supposed to have built in namespacing, but as an ObjC dev I couldn’t help myself lol
Guido van Rossum is very clever. That ends up being the source of a lot of python quirks like this. This is definitely a very clever way of implementing private variables in python with minimal overhead. In practice it turns out that people just never use it because its behavior is too strange. It's also difficult to figure out what would be a better solution given the design constraints of the language (that every object is basically just a dictionary of key value pairs). Somehow adding real private scopes seems "unpythonic", although I can't explain why. I think a lot of the confusion end up because the behavior results from a "magic" naming convention. Python doesn't really like adding keywords for stuff like this, but I can't help but think if name mangling was somehow linked to a "private" qualifier, that this confusion would not exist. That would have a drawback too though, in that you would have to qualify all uses of the field with "private". That's essentially what python already does actually, except they spell "private" (confusingly) as "__".
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.
Always thought: no underscore == public; single underscore == protected; double underscore == private. Don't see what the problem is. Also, can be thought as: no underscore == stable; single underscore == internal, can be changed at any time; double underscore == don't touch me. In my ten years programming in python name mangling has never been a problem.
This is so awesome! So thorough but simply shown
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.
I have heard that the single underscore is preferred because you don't know how your classes are going to be used. Using double underscores ("private" variables) makes classes that have them unfriendly.
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.
Hi there! Could you please make a review of new features of 3.11 release of Python? Thanks for your work!
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 does the run-time naming handle conflicts between mangled names? If the mangled name ignores leading underscores in class names, could you not have some class "_____A" (5 underscores) and another class "____A" (4 underscores). If both of these classes have some internal variable __x, how would their mangled names be handled?
Your channel is awesome!
Thanks so much!
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.
A really good break down of the issue. Thank you☺
Man, I thought I understood this. Thanks for disabusing me of that misconception.
What SHOULD happen, if it were designed properly, is an attempt to access the "private" variable __count would throw an exception for an access violation. This would put python in the same camp as other languages that have public and private keywords for class variables. Instead, it just mangles the name and it's on the programmer(s) to play nice and not abuse or work around it.
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.
This is a very informative yet, a very funny video, nice one james.
I guessed it will print 0, got the reason right. It was a first for me
Just don't touch underscored vars from outside. It is for a reason that they are considered to be private.
I did know about this, but the details get fuzzy after a while. I think the solution whenever possible is to use composition instead of inheritance, anyways.
1:23 what's that R🖊 icon shown near the line number 32's gutter in the pycharm?
This video seems like you rage quite a project and just had to vent in the most productive way possible
OMG, thanks for the info! It was frightening before going to bed tonight.. :-O
Who are these people naming stuff with double underscore if they didn't intend to name mangle!
One more reason to choose functions over classes whenever possible 😀
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...
What if you mix manual and automatic mangling? Does it refer to the same variable?
6:24 -ish, but if it always fixes one underscore name in mangling always, does that mean it can generate conflicts? Like, if you daresay have classes A, _A, and __A (double underscore) in the same project, would all 3 resolve to "_A__variable" names?
It would seem so but keep in mind they are "kept" under their respective class anyway
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 -.-
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!
Seems like any use of a variable starting with double underscore other than "self.__foo" in the class definition should be an error.... (or warning.) Is there a function that returns the mangled name as a string, given a variable or property? (For setattr()/getattr(), debug messages, etc.)
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.
10:53. can you have a base class or mixin class _MyMangler: @classmethod def _mangle(cls, attr): return f""_{cls.__name__}__{attr}_" so internal getattr(attr, self) are replaced with with getattr(self._mangle(attr), self).... not that I would ever do that.
Fantastic unexpected feature that I don't even supposed about!!!
lmao this video gets more and more hilarious as it goes, i love it
5:00 I feel thrown back to JavaScript's evaluation of values and how the weirdest shit can end up as false, true or just a string...
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 took a deep breath with you.
type checkers catch this right? like mypy or pyright?
My brain is now positively mangled after watching this.
You better see a __private practitioner!
heyyy what theme do you use for your vs code ? I have seen it before but I couldn't find it
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!!!
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.
Python students taught by instructors that do not know better HAVE to fall for this, because those instructors would not know that Python classes do not have true private variables, unlike the languages they know (e.g. Java, C++) Don't ask me how I know. Haha
@mCoding this seems utterly horrendous. But can it be made even more horrendous by combining with __slots__ ? And if so, how would such a monstrosity work?
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.
So do we use __x for sudo "private" variables or should we just omit them entirely and have everything public by default like always.
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
I tipically use name mangling in my projects and I've never had any issues with it regarding bugs or unpredictable code. But I guess that's just because I wasnt a moron that despite knowing those variables shouldnt be touched outside the class still attempted to do so...
Just a feedback, the memes are kinda disrupting my focus and maybe of some other users too, i liked your previous video types, where we had no memes in between jumpscaring, just your serious voice and some serious feature analysis, thanks.
I thought the convention was that a single underscore is supposed to represent a private variable. I don't recall hearing anything about two starting underscores. Edit: just got to the point in the video where he confirms that
this channel is incredible. can anyone recommend me other coding channels as good as this one?
I've never liked embedding semantic information into variable names, feels old-fashioned a little like Hungarian notation.. This feels like a funny way to build around something that is already not great. Are there channels similar to this one which detail quirks of other common programming languages like Java?
This name mangling is fine, it solves a real world problem. The only issue is with the rare side effects of the poor implementation, for example when modules a mangled (and sometimes not). But they're rare because mangling local variables is not an issue, after all it's already local, who cares of the name python uses to access the locals dictionary. That's why I think it's fine as it solves real world problem, as explained in the video. Speaking of the video, it focuses too much on those side effects that you will never hit, and if you do you can always look it up. I'm afraid that videos like this one deter programmers from python, thinking "wow this language is unpredictable".
It will be interesting to investigate those cases applied to Cython...
I feel like if you need name mangling functionality, name-space your private methods/members by manually mangling instead so there's no dark magic
Great explanation!
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
8:48 I saw 424242 and immediately thought of b"BBB"... I wonder if you can use metaclasses to make this even worse. (Or maybe make it function "as you'd expect"?)
If you treat it genuinely like a private field, then it kind of works. You just need to know that private things exist. But yeah I remember seeing the mangled name in my debugger for the first time. Wild…
I'm new to python, coming from Typescript. I had no idea you could do name Mangling as a means to set variables to private and public. Time to whip out chat GPT to learn more .
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.
This applies to "private" methods as well
I've always felt a little bad not using `__` on my instance variables, but apparently this feature isn't all its cracked up to be lol
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)
@6:30 perfect use of focus mangling. lol
i understand the tradeoffs of the different conventions for "private" variables, but i don't understand this last bit at the very end of the video: "in the wild, the most common approach is to use the single underscore and to just hope subclasses don't clobber your implementation details. if you're very good about keeping your classes defined as if they were statically typed, then you could also write a linter rule to help you." what would the linter rule be, and how would it help you with this problem? my guess is that you would just have your linter forbid you from overriding variables, but i dont see why this only makes sense in a context where you've defined your classes as if they were statically typed. id appreciate if anyone could shed some light!
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
Its not confusing at all if you regard any identiifier that begins with one or two underscores from being untouchable from outside the class, and severely dicipline any coder you catch trying to "reach around" the mangling. If you are trying to access a "psuedo-private" or mangled name then you know you are doing the wrong thing. If you need to access that mangled value, add in a getter/setter function to the class and do it the right way. Python has never pretended to protect you from your own stupidity. If you don't trust yourself to behave, then maybe try C++ or Java instead.
Thanks! I saved this video to just throw the link at the person who would ever ask me: -why do you hate python?
Wow. I had a use for this feature 3 days ago, and I had long forgotten about it. I just refactored my code so that I no longer had a use for this feature. Maybe I'm better off forgetting it again.
I wasn't aware of this, but it makes me glad that I don't start my member variables with __.
Woooa, I knew about this feature, but I didnt know how cursed is it. You can fell into this even if u don't use "private" variables.
Have a like for the anger fade. Perfect! Interesting content too
God I stuck on this bug once for days in Pygame where layers are set in the exact same way
1:48 I think this behaviour is pretty nuts. They should rather give out an error, if you access a variable that's supposed to be private. But that's just my opinion.
So... what would happen, if I imported your Widget example, inherited from it, and my class would also be named Widget, and I also defined a `__count`? Both should mangle to `_Widget__count`. So the mangling wouldn't even meet it's purpose because we chose weird names? Weird.
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.
What about the option where you tell people to not access a property directly and always use the setter/getter and if there is none defined for an attribute, it's because I don't want you to use it and if you do use it, then well, you get to support all the bug tickets from your now-broken code? Is there a reason why I wouldn't want to do that?
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.
Oh no this’ll be super difficult whenever I have to name a variable a word that starts with 2 spaces
Hey James, Has anyone ever told you, you sound like "Corey Schafer" -- another renowned name in the Python community.
"buuuut your code looks horrible, and your co-workers hate you" :))))
The whoosah deep breath is something I'm gonna watch every morning
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 video started like something obvious, but actually I didn't know that "mangle" works so weird.
This is one of those things that drove me so bonkers when I was trying to figure out how to do [whatever] with objects in ren'py that I just. gave up and picked a way that didn't involve objects at all. I wonder if going back to it with the context in this video would help at all?? Something to try next time I feel like learning by tying my brain in a knot for sure.
I too tried once to use Ren'py. Couldn't get it to work, got frustrated and left it.
@@daniel_rossy_explica I'm way stubborn, so I've gotten okay at it, but it really is one of those things you HAVE to be stubborn to learn! Every time I flip over a "surely there is a straightforward way to do [whatever]" rock, a million "lol no. change the source code" bugs crawl out from under it..
@@dovedozen From what I remember there is close to no documentation either so you HAVE to look at the source code to understand it. And then they have that strange way of writing scripts for the games. I remember thinking "why don't you just use straight python to make the games instead of this complicated parser?"
@@daniel_rossy_explica Ooh but the parser taught me how parsers work; I'm legitimately fond of it now 😭 And the documentation has definitely gotten better, although if you're not checking the discord and forums you definitely miss out on a lot! Then again I've never really encountered anything open-source that had GOOD documentation, so maybe I just don't know how good it could be? Also, the script thing is fantastic for lazy people (ME (WROTE AN ENTIRE CUSTOM THING TO AVOID HAVING TO USE BRACKETS ROUTINELY (TOOK WEEKS but made me feel like a WIZARD))).. you would not believe how much of my ability to write VN stuff is predicated on the programming part being as brainless as possible; Writing Brain and Programming Brain are NOT friends with each other.
@@daniel_rossy_explica ok I say the documentation is fine and IT ISN'T BAD but I just remembered that I had to learn to print dictionaries to find out that the reason changing a thing called "name" wasn't working is because it was actually called like. "something_name" internally & it was very much not written down anywhere that this was the case so. again I may just be living in the dirt over here