__init__ in Python already has a lot of alternatives. IMO a situation encountered similar to the example is when you do not take advantages of the alternatives or your code design is bad.
Also, specifically for this case, if I need an object for this IO operation, I __would not__ uses dataclass. The first solution would be to create a context manager[2] and a NamedTuple (or dataclass if needs some mutations). If it's not a fit, the classmethod and the dunders __enter__, __exit __ are good if this fd implementation is important for the design of my object. Alternatively, I would just make a builder function outside my object if the implementation of the fd capability should be considered as extra and not a builtin for the object. The dataclass decorator could be added to save 1 line of code but would confuse the intent of the object which is a content manager with some state management.
A side geniune question, why not a type[3] statement to alias the int as a fd? What is the difference with using NewType[3]? In which situation creating a NewType from a base type - here int - is useful?
[1]: https://docs.python.org/3/library/collections.html#collectio... [2]: https://docs.python.org/3/library/contextlib.html#contextlib... [3]: https://docs.python.org/3/reference/simple_stmts.html#type [4]: https://docs.python.org/3/library/typing.html#typing.NewType
I even run my entire Voron 3D printer stack with podman-systemd so I can update and rollback all the components at once, although I'm looking at switching to mkosi and systemd-sysupdate and just update/rollback the entire disk image at once.
The main issues are: 1. A lot of people just distribute docker-compose files, so you have to convert it to systemd units. 2. A lot of docker images have a variety of complexities around user/privilege setup that you don't need with podman. Sometimes you need to do annoying userns idmapping, especially if a container refuses to run as root and/or switches to another user.
Overall, though, it's way less complicated than any k8s (or k8s variant) setup. It's also nice to have everything integrated into systemd and journald instead of being split in two places.
I believe the podman-compose project is still actively maintened and could be a nice alternative for docker-compose. But the podman's interface with systemd is so enjoyable.