7 ms·
Python has been getting bloated in recent years. Why not just do the following? def enum(*args): return dict(zip(args, range(len(args)))) colors =
by jjs 13y ago
Python has been getting bloated in recent years. Why not just do the following?
def enum(*args):
return dict(zip(args, range(len(args))))
colors = enum('red', 'green', 'blue')
# {'blue': 2, 'green': 1, 'red': 0}
- pavpanchekha 13y agoThere are a few things this proposal does that improves upon yours: + Enum values of different types are incomparable. This is widely seen as a good thing. + Enum values are instances of their Enum; this allows more flexibility in user code. + As a result of the above, you can have a dictionary without Enum values of two different types colliding. + Enum values print in a more friendly way. This is expected to help debugging. + To support the above, enum values know their own name. This is likely helpful both for debugging and for various introspection hacks. + Enums can be iterated over in a fixed order. This allows automated help systems and similar to maintain consistency between runs, improving user experience. + There's a lot more error checking provided to avoid cases like defining the same enum value twice. But I understand your sentiment. We always enjoy smaller languages because it helps us keep them in our heads. But note that Enums aren't a new language feature -- this PEP simply adds another module to the standard library. The code your provide, flawed as it is, is still a pattern common to many different libraries, so it would be good to put it into the stdlib; but if we're doing that, might as well do it right, don't you think?
- jjs 13y agoFair enough. The enums themselves aren't a problem; they just seem symptomatic of a pile-on-more-stuff mentality.
- deleted 13y ago[deleted]
- jayflux 13y ago"Python has been getting bloated in recent years" Didn't Python 3 do more removing/tidying up than actually adding of stuff?