> ORMs—built specifically to fix this—still fail at 88%

How so? The only way to do anything dangerous using any orm I've used was when I needed to do something orm doesn't support and I had to extend it, operating at a text layer (custom db syntax or non-standard sql extension). 99% of sql users wouldn't event know how to get there.

Yes, by deciding on when, where and how you pass it. You know when it is created and destroyed because you wrote the code that either does that directly, or follows the convention (destroy when out of scope, or use of arc - it is programmer's decision).

> Much of the business world, especially those things that must be done properly, still rely on having physical records and manual process.

Can you name one business that is using physical records where this is not mandated by law? All accounting around me, including banks, is done digitally. The only one I can think of are businesses run by people born before computers where a thing (some still exist). Note that governments and regulated industries can change very slowly, but that's almost always result of not needing to compete, not an intentional choice.

> Why would you need to treat a web browser like a virtual machine?

There are many reasons. Performance, ability to bring concepts from other domains, ability to do things browser has no api for, ability to provide controlled experience and behaviour that goes beyond common browser usage.

> surely we can't keep adding to css and the dom api's for 20 more years?

We can. Just every now and then some new way of working becomes popular, and at some point combining them with older ones will become undefined or unsupported.

> why did some of them find (and take) room in coin hoards?

People who had access to gold used some of it to create jewellery.

> Why have they been found all over Gallia, Germania, and Britannia, but not Italia, Hispania, or the Oriens?

Certain types of jewellery can be found in certain regions. This can be attributed to specific trading network or local preferences. I don't know if that could be proven, but makes sense to me.

Knitting spools are not jewellery.

Knitting - specifically knitting jewellery - explains that. Different holes allow you to create chains of different sizes, which in case of jewellery, also does not need to be standardised (lack of any standard or markings makes theories of some measurement device unlikely). That also explains regional popularity and proximity to gold (several of those items were found close to places were gold coins were produced or stored).

No, knitting of gloves: https://www.youtube.com/watch?v=76AvV601yJ0

And none were found in Italy or in the South. Guess what, you don't need gloves there in the winter.

> 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

Look at prql for example of better alternative. I'd love to have something that works with modern programming languages without translation. Also is extensible. The list of complaints one can have SQL is long, and many modern databases leave it behind.

I've found recently that CORS doesn't work with it, which kills it for a lot of usecases.