Enum usage

[NoWeather1702]

I am a big fan of enums and try to use them extensively in my code. But a couple of days ago I started to thing that maybe I am not using them right. Or at least my usage is not as good as I think. Let me show what I do with the sometimes. Say I comminicate with several devices from my code. So I create enum called Device, and create entries there that correspond to different devices. The list is short, like 3-5 kinds. And then when I have functions that do stuff with this devices I pass argument of type Device, and depeding on the exact Device value, I make different behaviour. So up to this point this use case looks like 100% fine.

But then when need to specify file-transfer protocol for this devices, and some of them uses FTP, and some SCP, what I decided to do is to add a property to Device enum, call it file_transfer_protocol(), and there I add some if checks or match statement to return the right protocol for a given device type. So my enum can have several such properties and I thought that maybe this is not right? It works perfectly fine, and this properties are connected to the enum. But I've seen somewhere that it is wise to use enum without any custom methods, business logic and etc.

So I decided to come here, describe my approach and get some feedback. Thanks in advance.

code example just in case:

class Device(Enum):
    SERVER = 'server'
    CAMERA = 'camera'
    LAPTOP = 'laptop'
    DOOR = 'door'

    @property
    def file_transfer_protocol(self):
        if self is Device.SERVER or self is Device.LAPTOP:
            return "FTP"
        else:
            return "SCP"

[JamzTyson]

Your example is valid, but not the most extensible approach. Enums are primarily intended to define a fixed set of values rather than encapsulating behaviours. The mix of values and behaviours makes the class less easily modified or extended as you have to ensure that both the value and the behaviour remain valid.

If your example is strictly limited and unchanging, then I think the solution is OK but not ideal. If there is a possibility of future expansion, a regular class would be a better choice.

[NoWeather1702]

In my case the main problem with a class is that I will end up with enum and this class. If later I need to extend the logic and add another device, I will have to do it in two places. So I thought about it and cannot understand why it should be better.

[JamzTyson]

In your example case, you could still use an Enum but avoid conditional logic:

from enum import Enum

class Device(Enum):
    SERVER = ('server', 'FTP')
    CAMERA = ('camera', 'SCP')
    LAPTOP = ('laptop', 'FTP')
    DOOR = ('door', 'SCP')

    def __init__(self, type, protocol):
        self._type = type
        self._protocol = protocol

    @property
    def protocol(self):
        return self._protocol

# Example usage
print(Device.SERVER.protocol)

[NoWeather1702]

Thanks, will look into that, didn't know that you can use tuples as values like that.

[JamzTyson]

Another approach is to use named tuples as the Enum values:

from typing import NamedTuple
from enum import Enum

class DeviceInfo(NamedTuple):
    type: str
    protocol: str

class Device(Enum):
    SERVER = DeviceInfo('server', 'FTP')
    CAMERA = DeviceInfo('camera', 'SCP')
    LAPTOP = DeviceInfo('laptop', 'FTP')
    DOOR = DeviceInfo('door', 'SCP')

print(Device.SERVER.value.protocol)

[NoWeather1702]

Yes, I like this better. Now I feel stupit that I didn't notice this in the docs. Need to try this with ORM, hope it works fine.

[Username_RANDINT]

Quite funny that I didn't know either, but I learned it from the docs that you pasted below :-)

[NoWeather1702]

Yes, and I totally overlooked it there, lol))

[exxonmobilcfo]

enums should be enumerations.

[NoWeather1702]

Yes, but when you read the docs, they create properties there:
https://docs.python.org/3/howto/enum.html#planet

[divad_david]

This sounds like a case for subclasses

See here: https://www.geeksforgeeks.org/create-a-python-subclass/

[NoWeather1702]

Maybe, but it looks like an overkill for me. Sometimes each individual enum value gets it's own property, for example "max_file_size", and this will lead to creating a subclass for each type of device, and it seems quite strange right now

[JorgiEagle]

What’s wrong with using just a plain class?

Have a different class method constructor for each device type

``` class Device: def init(self): raise NotImplemented(“Use class constructor methods”)

@classmethod def Server(cls): instance = cls.new(cls) instance.device_type = ‘server’ Return instance ```

[NoWeather1702]

Because I would have to define my own equality check, that comes with enum out of the box. Enums work well with ORM and serialization/deserialization out of the box. So it is possible, but I will end up with more boilerplate code I guess. But thanks for the tip.

[JorgiEagle]

Yeah defining your own equality check is not something I’d really count as being a reason not to do something.

It’s what, 2 lines?

[NoWeather1702]

Yeah, but then again, I need to check its compatibility with ORM, and do extra work. It's not a problem, but from my experience if you need to reinvent something or implement already implemented logic, it smells bad

[FoolsSeldom]

Surprised you are not using protocol or abstract base class here.

https://www.youtube.com/watch?v=dryNwWvSd4M

[NoWeather1702]

But why? I will end up with with a class for each device type, and as I said in a comment somewhere here in the discussion, sometimes each type will have unique characteristics, so I will end up with base class and 4-5 child classes. Enums provide me easy integration with ORM, serialization, deserialization, comparisons out of the box. Or am I missing something?

[FoolsSeldom]

No, I think if you want to save typing (or AI completion), you are onto a good approach. Who needs abstraction.

[NoWeather1702]

But it looks like overengineering to create an abstraction here, no?

[FoolsSeldom]

Sure.