Hacker News Reader

Comment by thaumasiotes | Hacker News Reader

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?

View on HN

> 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.

> 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?

The 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.

Python 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

I'm not sure how "operator+" is supposed to be appreciably different from "__add__".

One is a sensible choice a human might pick. The other is not.

Both are doing their job just fine?

So who were the non-humans who picked the one you don’t like?

They are both sensible choices that a human did pick, that's how they got into their respective languages.

They have different locality of behavior, for one.

I meant as a choice of name.

And what makes one name "special" while the other is only "pseudo-special"?

Funnily 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.

What's the use case for __foo -> _ClassName__foo? I've used python a bunch but never this feature, so I'm curious.

It 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.

It 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.

It'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.

Not when this can be done: https://gist.github.com/josiahcarlson/39ed816e80108093d585df...

Take a deep breath.

What 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`.

Reply on news.ycombinator.com