Calling iter() on a string enum

[jsangmeister]

Hi, consider the following code:

class Foo(str, Enum):
   BAR = "bar"

which creates a "string enum". Members and strings can be used exchangeably. Now, you can check for membership with the following code:

if "bar" in iter(Foo):
    ...

This works without problems, but mypy complains because the type of iter(Foo) is Iterator[Foo] instead of something like Iterator[Union[Foo, str]]. Is this possible with mypy? I do not want to add too much complexity to the enum, if possible. It looks like a mypy bug to me that the iterator type is not compatible with str.

[Daverball]

Starting with Python 3.12 you should be able to make this work with a simple if "bar" in Foo:, since __contains__ will also start working with enum values then.

But your main problem has nothing to do with types. It's that Iterator does not support __contains__, you will need to create a collection from the enum members. There are no type restrictions on __contains__, so mypy will never complain about the left hand side of a in conditional statement unless someone explicitly overwrote __contains__ with a more strict signature, but this would be LSP violation, so it shouldn't be a common occurrence.

As the comment below pointed out the code is fine, it looks like that specific check not working is a mypy bug, if instead of creating an Iterator you create a covariant Container type, then it will work without mypy complaining:

e.g. if "bar" in set(Foo): works just fine.

[TeamSpen210]

Actually the code is fine. Iterator doesn't have __contains__, but it doesn't need to. The in operator itself will fall back to iterating over the parameter and checking equality. You only need to define __contains__ if your class doesn't support iteration, or you can do it more efficiently.

[Daverball]

Alright, yes you're correct, it was late so I didn't look at the error reported by mypy close enough. I would open a mypy bug report for this, because a containment check for two disparate types should be fine, just like an equality check is as long as __eq__ was not overwritten to explicitly make it not fine. mypy complaining about it definitely seems incorrect.

I assume mypy went for the path of least resistance, but tried to at least be slightly type safe, since a custom __eq__ could potentially raise an error, since using in checks on non-containers shouldn't be a very common thing to do. What they probably should fall back to is checking __eq__ on the LHS against the return type of __next__/__iter__.__next__ on the RHS.

mypy will also complain about if "foo" in iter([1]): which is a weird thing to do, but it is technically type safe.