I read a post recently where someone mentioned that there is no need for using enums in python. I'm interested in whether this is true or not.
For example, I use an enum to represent modem control signals:
class Signals:
CTS = "CTS"
DSR = "DSR"
...
Isn't it better that I use if signal == Signals.CTS: than if signal == "CTS":, or am I missing something?
Signals.CTS does seem better than "CTS". But Signals is not an enum, it's a class with specific fields. The claim, as I've heard it, is that you don't need a separate enum language construct, as you can do things like you've done in the question, or perhaps:
CTS, DSR, XXX, YYY, ZZZ = range(5)
If you have that in a signals module, it can be imported as used in a similar fashion, e.g., if signal == signals.CTS:. This is used in several modules in the standard library, including the re and os modules.
In your exact example, I guess it would be okay to use defined constants, as it would raise an error, when the constant is not found, alas a typo in a string would not.
I guess there is an at least equal solution using object orientation.
BTW: if "CTS": will always be True, since only empty strings are interpreted as False.
I think there's a lot more to load on enumerations (setting arbitrary values, bitwise operations, whitespace-d descriptions).
Please read below very short post, check the enum class offered, and judge yourself.
Do we need Enums in Python? Do we need an html module, a database module, or a bool type?
I would classify Enums as a nice-to-have, not a must-have.
However, part of the reason Enums finally showed up (in Python 3.4) is because they a such a nice-to-have that many folk reimplemented enums by hand. With so many private and public versions of enumerations, interoperability becomes an issue, standard use becomes an issue, etc., etc.
So to answer your question: No, we don't need an Enum type. But we now have one anyway. There's even a back-ported version.
It depends on whether you use values of Signal.CTS, Signal.DSR as data. For example if you send these strings to actual modem. If this is true, then it would be a good idea to have aliases defined as you did, because external interfaces tend to change or be less uniform when you would expect. Otherwise if you don't ever use symbols values then you can skip layer of abstraction and use strings directly.
The only thing is not to mix internal symbols and external data.
If you want to have meaningful string constants (CTS = "CTS", etc.), you can simply do:
for constant_name in ('CTS', 'DSR'): # All constant names go here
globals()[constant_name] = constant_name
This defines variables CTS dans DSR with the values you want. (Reference about the use of globals(): Programmatically creating variables in Python.)
Directly defining your constants at the top level of a module is done in many standard library modules (like for instance the re and os modules [re.IGNORECASE, etc.]), so this approach is quite clean.
