First, rudimentary/basic enums are as simple as instance variables on a class and allow super-helpful IDE "auto-completion" that doesn't necessitate the use of magic-strings to at least "set" the enum. I've been using this ridiculously simple trick since 2.5 ten years ago. Magic-strings are bad, and even worse when you have a disparate code-base in a dynamically typed language. Example:
class MyEnum(object):
Pass = 1
Fail = 2
my_value = MyEnum. <-- at this point, the IDE gives you code-completion.
class MyEnum(Enum):
Pass = 1
Fail = 2
def my_func(did_they_pass: MyEnum):
if did_they_pass.Something: # IDE / type-checker will go nuts here.
print("Something")
Because magic strings are bad.
And, moreover, this will inspire me to ask "How many other traditional magic numbers/strings/etc have I gotten used to that might be defined more readably?" strcmp, I'm looking at you!
I know your post was sarcastic/snarky but it was genuinely helpful
https://docs.python.org/3/library/os.html#os.SEEK_CUR
I wish the docs on f.tell at least mentioned the option
https://docs.python.org/3/tutorial/inputoutput.html#methods-...
This is conclusive proof that you're not actually aware of the capabilities of enums and sum types in "statically typed languages". Where's pattern matching? Exhaustivity checking? Sum types? GADTs?
sorry i don't understand this. i'm not trying to be pedantic but: statically typed (and type-checked) language will fail to compile ... not just warn you. that's not a 1% difference that's the entire difference (because lots of people will miss or flat out ignore ide hints).
Enums represent a discrete set of constant values. They are extremely helpful to communicate to developers what to expect from a component. Lists of strings do not come near to offer the same functionality.
There are also good reasons why Python does not have switch/case statements, which are generally an anti-pattern; they work fine for a quick fix, but what they do is better solved with proper polymorphism.
Also I'm sure with reflection you can actually implement a simple enum pattern matching function on an enum that is exhaustive and throws a runtime error immediately if every possible enum case is not covered.
I.e. if you're working with python Enums, you type-check for that Enum, and then the IDE does it all for you. If you want to "check" for a specific enum, then you cast to it and the runtime Enum implementation does that checking for you by throwing an error if you try create that Enum with an invalid string value. And if you've got a raw string, before it goes too-far into your code base, you cast it into the specific Enum type, and when serializing you serialize it to the string value. Easy-peasy.
as someone else in this thread pointed out [0], it's possible with MyPy when using if/elif/else, or if you did it with a dictionary lookup, you could write a very simple test that checks that the set of enum values is equal to the dictionary key members. I've done this before, it works well [1].
[0] https://news.ycombinator.com/item?id=23441023 [1] https://github.com/aws-cloudformation/cloudformation-cli/blo...
The second part of crimsonalucard1's post was referring to somehow hacking in that type of functionality into Python.
I think you could somehow do that with nested context managers - something like:
with EnumChecker(e) as checker:
with checker(enum_type.A):
# do thing
with checker(enum_type.B):
# do thing
...
switch(value: bool):
case True:
// do something
case False:
// do something else
end
So imagine where someone writes this code:
switch(value):
case True:
// do something
end
The power of this basically allows you to encode safety of if else logic into a type and pass that safety throughout your program. It's pretty incredible, so much so that whenever this feature is part of a language I have stopped using if else statements almost completely.
Keep in mind the power of pattern matching extends beyond just exhaustive enums. An int is a form of enum as well:
switch(value: int):
case 0:
// do something
case >0:
// do something else
end