I’m fairly sure you can do better than that just defining the appropriate dunders.
…Ok, it seems to me an overkill, but…
I can create the class OpenFlag(str), with three attributes, type, data and update, that will implements __or__ in such a way that, for example, a | b will return a new OpenFlag, with the attributes of a and any of the three attributes of b that replaces the relative attribute of a, if it is not null and the relative attribute of a was null. If both are not null, an exception will be raised. The __repr__ of OpenFlag will return a string that is a concatenations of the three attributes, when they are not null. So the enum will became:
class OpenMode(OpenFlag, Enum):
read = OpenFlag(type="r")
append = OpenFlag(type="a")
truncate_and_write = OpenFlag(type="w")
exclusive_create = OpenFlag(type="x")
update = OpenFlag(update="+")
binary = OpenFlag(data="b")
and, for example, "x+b" can be written as
OpenMode.update | OpenMode.exclusive_create | OpenMode.binary
Anyway no one can stop me to add also this one to the enum and name it exclusive_create_and_update_binary. You can use it or you can use the combination above or you can use "x+b", it’s up to you. IMHO
OpenMode.exclusive_create | OpenMode.binary | OpenMode.update
or
OpenMode.exclusive_create_and_update_binary
are much more readable also to someone that doesn’t know Python.
It’s pretty because it’s more readable. It’s useful because is more descriptive (I always forget that w is truncate and write…). And it does replace nothing, it only adds a more readable way to explicit how you’re opening the file, that you can use or not.
And the point is Readability counts.