4 ms·
Probably the system of giving special meaning to what are otherwise ordinary identifiers. __ isn't a reserved keyword in Python or anything. But there's a set o
by thaumasiotes 1y ago
Probably the system of giving special meaning to what are otherwise ordinary identifiers. __ isn't a reserved keyword in Python or anything. But there's a set of conventions you're supposed to follow when naming methods and attributes, and they're visibly artificial. It would be cleaner to make the features that are a special part of the language definition also a special part of the language syntax instead of running them in indistinguishably with other nonsimilar things.
In C++, if you want to define the binary + operator on a class, you give the class a method with the special name `operator+`. In Python, to do the same thing, you give the class a method with the pseudo-special name `__add__`. You don't think the Python way is worse?
- reverius42 1y agoI'm not sure how "operator+" is supposed to be appreciably different from "__add__".
- brabel 1y agoOne is a sensible choice a human might pick. The other is not.
- orphea 1y agoBoth are doing their job just fine?
- acdha 1y agoSo who were the non-humans who picked the one you don’t like?
- dragonwriter 1y agoThey are both sensible choices that a human did pick, that's how they got into their respective languages.
- WesolyKubeczek 1y agoThey have different locality of behavior, for one.
- reverius42 1y agoI meant as a choice of name.
- reverius42 1y agoAnd what makes one name "special" while the other is only "pseudo-special"?
- acdha 1y ago> You don't think the Python way is worse? Have you considered how much familiarity might shape your reaction to the two? Both are specific patterns with arbitrary restrictions which new learners have to internalize, and that’s a fairly advanced task most people won’t hit until they are familiar with the language syntax. Here’s a counter argument: the Python methods are normal method declarations whereas C++ developers have to learn that “operator=“ means something different than what “operator =“ (or any other assignment statement) would mean, and that this is the only context where you can use those reserved symbols in method names. To be clear, I don’t think either of these is a big deal - the concepts and usage are harder to learn than the declaration syntax – but I think it’s incredibly easy to conflate familiarity with ease of acquisition for things like this.
- thaumasiotes 1y ago> Have you considered how much familiarity might shape your reaction to the two? It doesn't. > Both are specific patterns with arbitrary restrictions which new learners have to internalize, and that’s a fairly advanced task most people won’t hit until they are familiar with the language syntax. No, the Python methods are just ordinary methods with valid names. What 'arbitrary restrictions' are you referring to?
- acdha 1y agoThe arbitrary restriction is that you have to just learn a specific pattern and follow it. I can’t have my Python class use “addition” if I hate underscores or my C++ code use “mathematical_division” if I’m horribly pedantic. In both cases, it’s just a particular design decision by the language developers I have to learn, and in both cases I won’t think much of it after the initial acclimation.
- yunwal 1y agoPython you have to learn something arbitrary for each dunder method you want to define/override. + —> __add__, * —-> __mul__, etc C++ it’s just one pattern to learn, x -> operatorx
- kemayo 1y agoFunnily enough, just starting your class method/variable name with __ does do magic things as a pseudo-keyword. Specifically, it mangles the name for callers outside of that class -- `self.__foo` would need to be accessed as `obj._ClassName__foo`. It's python's approach to having private methods, while remaining somewhat ideologically opposed to them existing. This doesn't apply to the dunder methods, though. They're magically exempt from this magical mangling, so you could call them directly if you wanted. ¯\_(ツ)_/¯ > You don't think the Python way is worse? They seem about equivalent? I don't see any real reason to pick one or the other, beyond personal preferences.
- wasabi991011 1y agoWhat's the use case for __foo -> _ClassName__foo? I've used python a bunch but never this feature, so I'm curious.
- kstrauser 1y agoIt makes it nearly impossible to reference that attribute by accident. Basically, if class Foo defines "self.__bar", the Python interpreter sees the leading "__" and mangles it. It's the lightweight equivalent of a private attribute in other languages, with the difference that Python will let you attempt to access it anyway. But if you do, and it makes your code utterly brittle and prone to explosion, no one will give you sympathy or help you fix it. They're much more likely to tell you not to do that.
- dragonwriter 1y agoIt prevents accidentally overriding the member in subclasses which can prevent private implementation details of parent classes from being accidentally interfered with by child classes. As composition over inheritance becomes more idiomatic, there are probably less places where this matters, but as long as inheritance is used at all it can be useful.
- antod 1y agoIt's as close as they'll get to private methods while still having the "we're all consenting adults" philosophy that doesn't prevent you doing something dumb. Or if you use this and it breaks, you can't say you weren't warned.
- DrJosiah 1y agoNot when this can be done: https://gist.github.com/josiahcarlson/39ed816e80108093d585df94f2dbc8b7 https://gist.github.com/josiahcarlson/39ed816e80108093d585df... Take a deep breath.
- thaumasiotes 1y agoWhat problem is that addressing? It doesn't solve the problem that `__add__` is a valid identifier -- so is `add` -- and it also doesn't solve the problem that there is no connection between the symbol `+` and the name `add`.