Hacker News Reader

This is precisely the thing I do not want from python. Subclassing is super useful in convoluted tests where fakes are superior to mocks. I don't like being told "you can't do this" by some library's code.

If it's enforced at the type-level then, don't check types during your test runs? shrugs

It would be enforced by the optional static type checker, not the language runtime.

And if you want to enforce it at runtime you already can!

    class Final(type):
       def __new__(cls, name, bases, dct):
           if any(isinstance(base, Final) for base in bases):
               raise TypeError("No!")
           return type.__new__(cls, name, bases, dct)

    class NoSubclasses(metaclass=Final):
        pass

    class WillThrow(NoSubclasses):
       pass

From my experience with Kotlin, sealed classes aren't really used for classes you'd like to fake in tests - they're usually used to have an exhaustive list of data types with different parameters, basically enums on steroids. Kotlin has recently added support for sealed interfaces, which would potentially suffer from the issue you described, but I haven't found a compelling use case (or any usage in wild) for sealed interfaces. If anything, I'd expect it to be used for types that explicitly shouldn't be faked by the library consumer anyway

You can already have exhaustiveness-checking by the type checker right now today.

    from enum import Enum
    from typing import NoReturn


    class Stuff(Enum):
        Cat = 1
        Dog = 2
        Bear = 3


    def exhaustiveness_check(value: NoReturn) -> NoReturn:
        raise AssertionError()


    def do_thing(stuff: Stuff) -> None:
        if stuff is Stuff.Cat:
            print("meow")
        elif stuff is Stuff.Dog:
            print("woof")
        else:
            exhaustiveness_check(stuff)

And if you add a check for Bear it will validate it!

Okay but what if I need something more than an enum? Like if the stuff parameter is of type "BaseThing", and there are only meant to be five subclasses of BaseThing to check. I would want the type checker to verify that I dealt with every case. But without sealed classes, it can't determine that some other code that subclasses from BaseThing is wrong.

Absolutely! And since type checkers will likely never be able to implement support for __subclasscheck__ or __instancecheck__ the best we can ever do is annotations about the desired results of those methods. My only statement was that match isn't magic and you can do exhaustiveness checking (inasmuch as type checkers can detect it) without it.

Some more discussion in this thread

https://mail.python.org/archives/list/typing-sig@python.org/...

I have a fork of the "adt" library that supports sealed classes. For static type checking, I'm using a fork of typpete, a SMT based type checker.

It's not as user friendly as mypy or pyright, but in the longer term can be a winner because it supports user defined type constraints (aka refinement types).