On 26 April 2018 at 19:37, Jacco van Dorp <j.van.d...@deonet.nl> wrote: > I'm kind of curious why everyone here seems to want to use IntFlags > and other mixins. The docs themselves say that their use should be > minimized, and tbh I agree with them. Backwards compatiblity can be > maintained by allowing the old value and internally converting it to > the enum. Combinability is inherent to enum.Flags. There'd be no real > reason to use mixins as far as I can see ?
Serialisation formats are a good concrete example of how problems can arise by switching out concrete types on people: >>> import enum, json >>> a = "A" >>> class Enum(enum.Enum): ... a = "A" ... >>> class StrEnum(str, enum.Enum): ... a = "A" ... >>> json.dumps(a) '"A"' >>> json.dumps(StrEnum.a) '"A"' >>> json.dumps(Enum.a) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python3.6/json/__init__.py", line 231, in dumps return _default_encoder.encode(obj) File "/usr/lib64/python3.6/json/encoder.py", line 199, in encode chunks = self.iterencode(o, _one_shot=True) File "/usr/lib64/python3.6/json/encoder.py", line 257, in iterencode return _iterencode(o, 0) File "/usr/lib64/python3.6/json/encoder.py", line 180, in default o.__class__.__name__) TypeError: Object of type 'Enum' is not JSON serializable The mixin variants basically say "If you run into code that doesn't natively understand enums, act like an instance of this type". Since most of the standard library has been around for years, and sometimes even decades, we tend to face a *lot* of backwards compatibility requirements along those lines. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/