[docs] Code, test, and doc review for PEP-0435 Enum (issue 17947)

mm at ensoft.co.uk mm at ensoft.co.uk
Mon May 13 19:25:50 CEST 2013


http://bugs.python.org/review/17947/diff/8131/Lib/enum.py
File Lib/enum.py (right):

http://bugs.python.org/review/17947/diff/8131/Lib/enum.py#newcode14
Lib/enum.py:14: """ Returns the value in the instance, raises
AtttributeError on the class.
(minor) typo in "AtttributeError"

http://bugs.python.org/review/17947/diff/8131/Lib/enum.py#newcode56
Lib/enum.py:56: error is raised.
This sentence is not true (though it might be nicer if it was! i.e.
sometimes it might be easier when using the Functional API to just leave
duplicates in than round trip via an "OrderedSet").

http://bugs.python.org/review/17947/diff/8131/Lib/enum.py#newcode103
Lib/enum.py:103: enum_class = type.__new__(metacls, cls, bases,
classdict)
Shouldn't this technically be a use of super()? Not that I guess complex
type hierarchies of Metaclasses are common.

http://bugs.python.org/review/17947/diff/8131/Lib/enum.py#newcode114
Lib/enum.py:114: if not isinstance(value, tuple):
Doesn't this produce weird behaviour for the following definition:

class MyEnum(Enum):
    FOO = 7
    BAR = (42, 8)
    BAZ = "hello"

http://bugs.python.org/review/17947/diff/8131/Lib/enum.py#newcode123
Lib/enum.py:123: enum_item = __new__(enum_class, *args)
Is it explicitly forbidden to have multi type enums (i.e. ones where
different items have different values)? This code assumes that the
__new__ from the first type can cope with the args from the latter ones.
I believe the __new__ needs to be re-calculated on each enum item in
order to correctly cope.

http://bugs.python.org/review/17947/diff/8131/Lib/enum.py#newcode323
Lib/enum.py:323: Enum.__new__):
This should be a set literal, not a tuple.

http://bugs.python.org/review/17947/


More information about the docs mailing list