Every Python dev falls for this (name mangling)
HTML-код
- Опубликовано: 7 июн 2024
- 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 
Наука
![Natti Natasha - Quiéreme Menos [Official Video]](http://i.ytimg.com/vi/R57RrTjRGxk/mqdefault.jpg)
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.
6:26 - this is golden, you've really managed to capture and portray everyones feelings in 3 seconds
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".
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.
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 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!
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.
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.
This is one of the many reasons why I tend to avoid OOP at all reasonable cost
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.
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.
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.
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....
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.🥺
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?
This is so awesome! So thorough but simply shown
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.
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
You just flipped my world and I'm surprised I never ran into this issue before. Must be because I rarely ever use classes.
This is a very informative yet, a very funny video, nice one james.
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.
Your channel is awesome!
Thanks so much!
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.
1:23 what's that R🖊 icon shown near the line number 32's gutter in the pycharm?
I love that for every rule you introduce, you sound increasingly embarrassed that they exist
A really good break down of the issue. Thank you☺
OMG, thanks for the info!
It was frightening before going to bed tonight.. :-O
Man, I thought I understood this. Thanks for disabusing me of that misconception.
Hi there!
Could you please make a review of new features of 3.11 release of Python? Thanks for your work!
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.
easy to avoid - don't use double underscores on class variable names if you plan to use them outside of the class.
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 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 -.-
Just don't touch underscored vars from outside. It is for a reason that they are considered to be private.
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.
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 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.
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.
"Well, let me introduce you to the questionable feature behind all of this confusion: classes"
@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.
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.
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 if you mix manual and automatic mangling? Does it refer to the same variable?
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.
I think maybe this is behind the "bug" I encountered a long time ago. I no longer have the code, and don't recall details. But I was parsing XML. The code worked in the console. It worked in script. It worked when imported by a script. But it did not work when imported by a supporting library... It would run. Just the result of the XML parsing would be empty. IIRC I ultimately got around it by restructuring everything around it so that I didn't need the 2 levels of import to use it...
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"?)
lmao this video gets more and more hilarious as it goes, i love it
type checkers catch this right? like mypy or pyright?
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.
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
I took a deep breath with you.
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?
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.
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!!!
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
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
The name mangling feature is weird and widely unknown. And it has a serious Silent Fail problem!
Doesn't the current convention say that if you want to protect fields then use only one underscore at the beginning?
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
Fantastic unexpected feature that I don't even supposed about!!!
This applies to "private" methods as well
It will be interesting to investigate those cases applied to Cython...
Have a like for the anger fade. Perfect! Interesting content too
this channel is incredible. can anyone recommend me other coding channels as good as this one?
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...
Whoa!! I'm so glad you made this video. I was literally jaw open watching this.
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!
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)
God I stuck on this bug once for days in Pygame where layers are set in the exact same way
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
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.
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…
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.
interesting overview, but i do use double underscore myself to denote private(although this is making me rethink that). On the one hand, I think you should NOT be able to access a variable that is suppose to be private from outside the class (which double underscore accomplishes), however on the otherside here, the ability to write a different double underscore variable from outside the class feels absurd. If we aren't going to get an language based update to block this, then perhaps we need a linter rule to block being able to write to double underscore from outside class implementation.
Private variables do not exist in Python. You are able to access everything by design. This is all about avoiding accidental name collisions.
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.
Wait, what? I thought we were told emphatically to not use dunder for private variables. Yet they have deliberate features for it?
Dunders are \_\_on\_both\_sides\_\_ of the variable name, not the same as name mangling. Don't use dunders for 'private' variables.
Name mangling is to prevent (the majority of) *accidental* name shadowing. You're always *allowed* to mess with whatever you want; if you mess with something marked as internal (anything with a leading _, except dunders - which are magic), it's assumed that you have a good reason for doing so and that you understand what you're doing; not unlike C's philosophy, although without the potential for memory unsafety.
TL;DR
public
_internal_but_might_be_useful_to_subclasses
__internal_but_specific_to_this
\_\_magic__ (powers stuff like len, str, repr, next; public but shouldn't be used directly by user code)
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.
Great explanation!
One more reason to choose functions over classes whenever possible 😀
How to split display in pycharm?
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...
Thanks! I saved this video to just throw the link at the person who would ever ask me: -why do you hate python?
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 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
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...
newbie developer here; can I just not use __ in my class variables? Feels like it's just adding more headaches than its worth.
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.
This video seems like you rage quite a project and just had to vent in the most productive way possible
To be fair in other languages nefarious authors can still access private fields via reflection (java), memory transmutation (rust), etc.
Who are these people naming stuff with double underscore if they didn't intend to name mangle!
This is a good feature. I’m gonna start using it.
What's the typeface?
I don't understand why it is an issue, since private fields are meant to be PRIVATE. If you try to publicly access a field that is private, then it's no wonder that you get unexpected behavior (though, I would have preferred an illegal access exception or something, but that is just my Java brain). So yea, you gotta know what double underscore means and how to use it properly and if you really need to access a private field from a public context, then make sure you know what you're doing.
In a way, prefixing the accessor of a private variable with _ in Python is like setting declared private fields to be accessible with reflection in Java. Both make private fields accessible, but they do it in a completely different way.
But you shouldn't get "unexpected behaviour", because that's simply confusing. You should get an error. I shouldn't need to "guess" that i made a mistake, i should know.
@@badoli1074 - that's the IDE's job -- not Python's.
I agree. Why would anyone access a "private" field from outside the class? The video creator says every Python developer will fall for this feature. This implies that every Python developer doesn't know what they are doing, at least at some point.
The whoosah deep breath is something I'm gonna watch every morning
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".
The video started like something obvious, but actually I didn't know that "mangle" works so weird.
What if your class is prefixed with double underscores?
should read pep8
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