I like that magic method names generally all follow the same form so it's obvious that they are magic methods and not intended to be part of the public API. Whether that form uses double underscores or something else doesn't really matter to me as they are not being called directly.

Would you consider a constructor magic though?

"Magic methods" is just the name people use for these special methods (another is dunder methods). They're "magic" because you do not call them by name, rather they are invoked by the interpreter in specific situations.

Yes, it is magic the same way other magic methods are, that is, because it is syntactically special and callable (and primarily called by) a syntax other than <instance>.<method>(...) or <class>.<method>(instance, ...)

Specifically, in the case of constructors, via <class>(...).

> it's obvious that they are magic methods and not intended to be part of the public API

Is there an alternative API? No. This is public API regardless of anyone's intentions. Though "it's weird" is really not a very strong argument against it.

Public API refers to the user of the class, not the implementer. You never call __init__ directly. __new__ allows modifying object creation itself for the implementer, but the user of the class will never call it.

There are private and public methods. Private methods are only supposed to be called within other methods, as in privately. Public methods are the ones that are normally called through the code, repl, by the user or whatever. You are not supposed to write `myclass.__add__(x)` anywhere except where you define the class itself and its methods.

There's actually 4 kinds:

  def foo(... # public
  def _foo(... # internal
  def __foo(... # munged
  def __foo__(... # magic

Internal is more convention as the language doesn't really do anything with it, but it does with munged, and magic methods are specifically for things implemented in the language.

Internal and munged don't exactly map to private and protected, but are kinda similar ish.

Oh right. I am not really into python, had read some doc about naming conventions some poitns.

In any case I actually like how one can use underscores to point on how exposed some method is supposed to be. Makes it simpler to actually know what to skip and what not.

There are several alternative API's. @dataclass is one, Pydantic offers another, there's also attrs, plus less general things like namedtuple.

Admittedly it's obnoxious when you've got habits for one and you're on a team that uses another--totally flies in the face of the zen re: "there should be only one obvious way to do things".

...but that was always a rather ambitious goal anyway. I'm ok navigating the forest of alternative API's if it means not being locked into something that I can only change by choosing an entirely different language. I'm happy that it's very easy to tell when somebody is mucking about with python internals vs when they're mucking about with some library or other.

@dataclass does a very specific subset of what overriding dunder methods does. It’s not duplicating an abstraction it’s layering them

You don't call __init__ directly so the ugliness is limited to the definition which seems fairly minimal to me. It seems to be a naming convention for methods that are not invoked by name anywhere and that's at least informative when you're reading the class definition.

IMO this is less horrendous than e.g. go's insistence that exported functions are indicated by a capital letter - that really affects code using the module not just the definition.

I had honestly not considered that the author might have been talking about the visual aesthetic of the dunder methods themselves. Honestly that has me a bit stumped; all I can say is that if you don't like underscores, don't pick python.

I have found to believe that ugly and beautiful are irrelevant. As long as it's doing the job and not cause major headaches. Life is too short to worry about syntax.

Right? I'm kind of surprised that a few underscores invoke such strong emotions in people.

> Life is too short to worry about syntax.

Every programming language you use will annoy you in some way. You stop caring after a few of them.

Can you elaborate bit what is the problem here? Is it shape of the characters or something else?

Amazing. If you need to ask this question I am guessing you have spent too long with Python . No other language uses this underscore madness for special methods or otherwise. Because it’s just , I don’t know a more appropriate word for it , stupid.

Oh yes they do: https://www.php.net/manual/en/language.oop5.magic.php

The programming languages world is broad/varied enough that any statement like "no other language does this!" is almost certainly wrong (outside of esoteric languages, which python and php most certainly are not)

Lua, too:

  __add, __sub, __mul, __div, __mod, __pow, __unm, __idiv
  __band, __bor, __bxor, __bnot, __shl, __shr
  __concat, __len
  __eq, __lt, __le
  __index, __newindex, __call
  __gc, __close, __mode, __name

What's actually amazing is how you're unable to answer a straight question.

If you call something "stupid" it doesn't really convey anything meaningful, especially not in the way you're using there, it comes across as "I don't actually have a reason I don't like it, I just don't".

I mean, Python is dynamic. Here, have this: https://gist.github.com/josiahcarlson/39ed816e80108093d585df...

Now you don't need to write your double-underscore methods ever again, if you don't want to.

Most C and C++ compilers use similarly named macros:

https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macro...

JS used to have those, now they are deprecated though:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

so it settled on having this syntax for similar cases using "Symbol":

class Foo { *[Symbol.iterator]() { yield 1; yield 2; yield 3; } }

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I’m not sure why you’re comparing __new__ to constructors in other languages.

Ruby has the same thing but it’s called ‘new’.

Implementing the type of customization (idiomatically) that __new__ provides in Kotlin and JS isn’t any cleaner.

That's kind of the point. These methods are never meant to be called directly. They're used to desugar.

I think it's fairly short sighted to criticize these. FWIW, I also did that the first time I wrote Python. Other languages that do similar things provide a useful transparency.

I don’t think anyone is criticizing its utility, just that the syntax of 2-5(?) underscores in a row isn’t something that is DX friendly.

The ugliness is intentional. Nobody wants to name their cool new variable __hot__singleton__in__your__area__.

The syntax is exactly two, not 2-5.

I think the point was: who can know by looking at it.

I mean, maybe you should use a font that doesn't make it hard to figure that out. Next you're gonna say we should ban 0s and Os, Is and ls, because your font doesn't allow you to figure out which one it is.

Anyone using a monospacdd font, a font where underscores are separated, or a run-together proportional font that they are even a little bit familiar with, because of the relative width of underscores and other characters.

Which, between them, covers approximately everyone.

They are called dunder methods, meaning "double under". It's 2 underscores.

I've had snippets in my editor for approximately 15 years at this point so I don't have to manually type any of the dunder methods. Would recommend!

It's like the bright orange garments that hunters wear, the ugliness is sort of the point. It says "this is a different sort of thing."

> It's like the bright orange garments that hunters wear, the ugliness is sort of the point.

Ugliness is not the point of hi-vis vests lol, the point is to not get shot by other hunters.

...by being as shockingly contrasting with their environment as possible. Maybe your aesthetics differ, but I find it quite ugly. If it wasn't, it wouldn't grab my attention so well. Wearing something shockingly ugly is a great way to not be mistaken for a deer.

By contrast, I find a well camouflaged deer quite beautiful--once I notice it at all. The beauty comes from the way that it is so clearly a thing of its surroundings. Nothing at all like a bright orange hat.

> Wearing something shockingly ugly is a great way to not be mistaken for a deer.

Sure... yes the bright orange is ugly, but it's not the ugliness that prevents you from getting shot, it's the bright unnatural color. Other hunters aren't thinking "oh that's really ugly, it must not be something I can shoot" they're thinking "bright orange means person, I should not fire my rifle in that direction".

> If it wasn't, it wouldn't grab my attention so well.

Are you saying that if you thought the bright orange was pretty it wouldn't occur to you not to fire your gun in its direction?

If I thought that bright orange was a part of a healthy forest ecosystem, I would likely see beauty in it. And if my intent was to shoot denizens of such an ecosystem, then yeah bright orange would make a poor indicator for "don't shoot here". You'd be better off with something ugly, something which clearly doesn't belong.

Some-other-language-user complaining about python ugliness:_____new_____ and _____init_____

Same-other-language-user:

((()))()()()({}{}{{(((())){}}}}{}{}{};;;;();)(;}}}

*not supposed to be correct syntax, it's just a joke

As if other language don't have their warts.. Ruby and Javascript for example have hideous syntax, comparing this with some special naming is quite bizarre.

But who cares? It's syntax, it has its purpose.

I would think the dumber thing is having to create an empty file called __init__.py for a package to register as a package. And relative imports being completely fubar.

> I would think the dumber thing is having to create an empty file called __init__.py for a package to register as a package.

This hasn't been true since Python 3.3. You no longer need a __init__.py for Python to recognize a module, but it can still be useful in many cases.

This is incorrect.

> The __init__.py files are required to make Python treat directories containing the file as packages (unless using a namespace package, a relatively advanced feature).

https://docs.python.org/3/tutorial/modules.html

The point is to keep them out of the object namespace, and works well for that.

I mean, it's never been a problem for me in my 26 years of Python, but if it is such a big deal for you, maybe you should consider this: https://gist.github.com/josiahcarlson/39ed816e80108093d585df...

I wrote it in about an hour and a half. It seems to work in Python 3.6 and 3.12. Now you never need to write another double-underscore magic method again.

Fewer characters than “initialize” or “constructor”, clearly marked as being “not a normal method”. Python is better here.

If you felt your argument about __new__ and __init__ was valid, you probably would have used the actual names and not hyperbolic exaggerations.