Before talking about Python, let's talk "sealed":
I also heard that the advantage of fully enclosed .Net / Java final / C ++ virtual classes is performance. I heard this from a .Net developer at Microsoft, so maybe this is true. If you are creating a powerful, highly sensitive application or framework, you may need to close several classes at or near the most profiled bottleneck. Especially the classes you use in your own code.
For most software applications, sealing a class that other commands use as part of a framework / library / API looks pretty ... weird.
Mostly because there is a simple workaround for any private class.
I teach Essential Test-Driven Development courses, and in these three languages I suggest users of such a private class wrap it in a delegating proxy server that has exactly the same method signatures, but they can be redefined (virtually), so developers can create test doubles for these slow, non-deterministic, or side-effects of external dependencies.
[Warning: below snark is intended as humor. Please read with activated humorous routines. I understand that there are times when sealed / final are needed.]
A proxy (which is not test code) effectively prints out (re-virtualizes) the class, which leads to searches in v-tables and, possibly, to less efficient code (if the compiler optimizer is not competent enough to embed delegation). The advantages are that you can effectively test your own code, saving living and breathing people weeks of debugging (as opposed to saving your application several million microseconds) per month ... [Disclaimer: it's just a WAG. Yes, I know your application is special. ; -]
So my recommendations are: (1) trust the compiler optimizer, (2) stop creating unnecessary sealed / final / non-virtual classes that you created in order to either (a) use every microsecond of performance in a place that is probably not in any case , your bottleneck (keyboard, Internet ...) or (b) create some kind of improper compilation time limit for the “junior developers” in your team (yes ... I saw that too).
Yes, and (3) write the test first. ;-)
Well, yes, there is always a mockery during the connection (e.g. TypeMock). You caught me. Come on, close your class. Whatevs.
Back to Python. The fact that a keyword is used instead of a hacker probably reflects the purely virtual nature of Python. It is simply not "natural."
By the way, I came to this question because I had exactly the same question. While working on the Python port in my very complex and realistic laboratory of legacy code, I wanted to find out if Python has such a disgusting keyword like sealed or final (I use them in Java, C # and C ++ courses as a unit testing challenge). This is apparently not the case. Now I need to find something as complex in the unverified Python code. Hmmm ...