There's no mandated order between compilation units. It's a problem significant enough to have its own snarky name: the Static Initialization Order Fiasco https://en.cppreference.com/w/cpp/language/siof
It only has i386, ppc, and arm64 slices. So, an Intel Mac running recent macOS won't be able to launch it as it does not have an x86_64 slice (32-bit x86 execution having been removed).
Whether an app containing code for 3 architectures qualifies as "true 5-arch universal" is in the eye of the beholder I guess.
> I know what's going on and my comment was sufficiently accurate to get the point across in 1 sentence. I wasn't exactly intending to get into a lecture on MRO here.
I was trying to not assume you were lying through your teeth about what Python method lookup is like in order to conflate fact and your personal opinion. Happy to be corrected.
> Which is much better than leaving a ticking time bomb.
It's a different implementation choice. That it is better is a perfectly valid opinion. Though, if A doesn't already know it's part of a multiple inheritance hierarchy it's not possible to know what __init__'s signature should be. I'm sure you're eliding that for a good reason, though.
> Er, yes it does. Every class instance in a hierarchy is initialized exactly once. Trying to call it twice will produce an error (e.g. "class has already been initialized").
This is true only for constructors, not arbitrary methods; __init__ in Python is much more arguably an ordinary method. I'm going to assume you're always using virtual inheritance, an opt-in feature, because otherwise you are being misleading and disingenuous in more ways.
> It does not. It's perfectly fine letting you call a class's __init__ multiple times. Unlike with C++.
True only for constructors in C++, and if you don't use super() in Python. Python treats __init__ and other methods fairly uniformly here.
>It is a fine word. "Idiosyncrasy" does not imply there exists only 1 person in the whole world engaging in the given practice:
>"Her habit of using “like” in every sentence was just one of her idiosyncrasies."
>https://www.merriam-webster.com/dictionary/idiosyncrasy
Sure, go off, but my point is that other languages you have heard of do the same thing. It's not some dumb thing Python is doing for no reason as you were implying.
> My point was what I said: you can have your cake and eat it too. You claimed the issue was due to a lack of a super keyword and I showed you it would not occur even if C++ had super.
I made no such claim. I said (in my opinion) C++ doesn't have the issue you're raising with Python because it has a completely different design that doesn't attempt to solve diamond problems in superclass attribute lookup. Are we not in agreement?
> I "brought it up" to illustrate it does one particular thing better than Python. Not to claim it does everything better than Python. If you want a simple, beginner-friendly language, avoid C++ like the plague.
You can validly think that C++'s choice here is better. I don't think there's a counterargument to personal preference here. My point was that it does not solve all of the problems Python's super builtin is designed to. And that's fine! It avoids the issue in question! I actually don't understand what you are arguing with here. Personally I think the design goals here are just so wildly different that I don't have a preference, but I admit that's kind of a cop-out.
> Idk, for starters maybe produce a warning when multiple inheritance occurs and one of the __init__s in the hierarchy doesn't call super().__init__.
In general I think having more "warning labels" on multiple inheritance is the right idea, if a language is going to persist in offering it at all. I think this would be a good start, especially for a linter.
> It's emphatically not "having a super keyword" or not having it. That's a red herring. Visual C++ has __super and yet it doesn't suffer from this: it errors with "ambiguous call to overloaded function" when there are multiple candidates
What's your point about this nonstandard extension? My point is that C++ doesn't have the problem of classes not written to be part of a multiple inheritance hierarchy delegating somewhere unexpected because, by design, it doesn't attempt to solve the same problems that Python is. If anything that this nonstandard extension doesn't work in multiple inheritance is agreeing with the points I'm making.
> There's a lot more I could say about this (frankly the issue I outlined just scratch the surface of a deeper problem in Python), but this is diverting the discussion. Nobody even said C++ is simple or somehow easier to learn than Python in the first place; I was just pointing out an insidious issue in Python,
You were the one who brought up C++! (EDIT: this was in a cousin comment.) My point is that different languages navigate this thorny landscape in different ways, but the way in which Python does isn't as haphazard as you are suggesting.
> Exercise for the reader: suggest improvements
Perhaps being part of a multiple inheritance hierarchy is sharp and uncommon enough that it should be opt-in. What are yours?
That's not at all what Python does. It linearizes the inheritance hierarchy for the purposes of superclass attribute lookup, in an attempt to solve some aspects of the diamond problem, or at least make them solvable. But it doesn't touch the types themselves, only the MRO used by the super builtin. That's why the super builtin type takes both the "current" class and the object instance itself, which was more visible before the whining of people who didn't understand it grew too loud to be borne by the maintainers and the project introduced the `super()` syntactic sugar. Not that I'm bitter about that or anything.
Anyway, your argument seems to be that you should be able to use naively written classes in a multiple inheritance hierarchy. I suppose that's a defensible opinion, but it's also not the case in any language I know of; C++ solves the problem of not calling the "correct" superclass by default by foisting the responsibility of choosing the correct subset onto the derived class author, but doesn't solve the "I called my superclass' method too many times" problem, only the "I have too many (n>1) copies of my superclass' data" problem (the solution to which is also opt-in). Python resolves all three of these, but in so doing requires careful construction of multiple inheritance hierarchies and use of the super builtin that is religious to the point of fanatical. That's a tradeoff made in respect to a feature that, IMO, is inherently sharp.
Aside: "idiosyncratic" is an interesting word to use given that the C3 MRO was originally intended for Dylan.
That, and: I forgot to mention that not using the super builtin can also lead to unintentionally calling a method twice or more for the same base class in a diamond situation (note that with new-style classes, all multiple inheritance has at least one "diamond" class, often object, but people normally do not delegate to object for obvious reasons; you can imagine a base class Z in this example that A and B inherit from instead, if you wish). So, not using the super builtin can result in both delegating to a superclass' implementation too much, and not at all! This is a problem with multiple inheritance that Python actually solves; virtual inheritance doesn't touch it.
Note that `object` being the root of the class hierarchy implies that you must have careful coordination between all classes in a multiple inheritance hierarchy to determine, for a particular method, when subclasses may/must delegate to super, what the arguments to the method are, and even what the argument names are in some cases! You can't just go glomming classes together and expect it to go well unless you know the classes either don't use the same method names or agree very carefully on what the delgatable interfaces are.
Now your class C can't necessarily be used in a multiple inheritance hierarchy with some other class D, and a class E that inherits from C and D, as C hardcodes what its parents are. Python uses the C3 MRO algorithm to traverse all relevant classes in your hierarchy when you religiously use the super builtin.
But; multiple inheritance is a beast in any language due to its complexity and bringing it up in a discussion of "magic" that python exposes beginners to is specious. It's true that C++ doesn't have this problem, because it has no super keyword and you must explicitly delegate everything, but also introduces the problem that you can have multiple instances of a base class and so has added complexity, virtual inheritance, to solve THAT problem. And tons of languages have a problem where omitting a call to "super" is logically required is not statically diagnosable.
The fuel for the large majority of the fusion energy in a thermonuclear weapon is lithium deuteride, a solid. But here's some theories now how this works, one of which is changing the amount of tritium gas in the primary; but note that the primary (no pun intended) purpose of the tritium in the primary is to boost fission output through neutron release
They can still get you if you invoke SSH on the remote, as the password is sent to the remote machine one character at a time, then forwarded on to your ultimate destination all at once.
I think you may be missing the point. These rings are given to graduating engineers not as a beautiful object of congratulations for their achievements, but as a token designed to remind them of the burden they have taken on.