Ethan Furman added the comment:
With the patch:
--> import enum
--> class Huh(enum.IntEnum):
... blah = 2
...
--> Huh.blah.from_bytes(b'\04', 'big')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/ethan/source/python/issue23640/Lib/enum.py", line 222, in
__call__
return cls.__new__(cls, value)
File "/home/ethan/source/python/issue23640/Lib/enum.py", line 457, in
__new__
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 4 is not a valid Huh
This is not the correct behavior. An IntEnum should act like an int, and in
cases where it can't and still be an IntEnum, it becomes an int. But this
behavior is Enum specific, and I would not expect other int subclasses to need
or want that behavior.
Also, in cases where class methods are alternate constructors there is no
requirement that they go through the main __new__/__init__ constructors to do
their job.
In other words, if IntEnum.from_bytes (which is inherited) is not behaving
correctly, it is up to IntEnum to fix it -- it is not the job of int, and this
is not a bug in int.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
