Repository navigation
Set dunder operators too permissive? #3184
Description
Similar to #1840
With #3181 I made KeysView consistent with Set but I really think the operators are confusingly permissive.
Let's look at them
# difference
{'1'} - {2}
reveal_type({'1'} - {2}) # => Set[str]
This should fail because this is always a null operation and thus
a programmer error.
# intersection
{'1'} & {2} # => Set[str]
reveal_type({'1'} & {2}) # => Set[str]
This really should fail because it is unlikely meaningful; the
return type is always an empty set thus it is also not a Set[str]
# sym difference
{'1'} ^ {2}
reveal_type({'1'} ^ {2}) # => Set[Union[str, int]]
Although the assumed union type is correct, Set[A] & Set[B] => Set[A|B] just doesn't make sense. The operator can only meaningful be applied to same type sets. What we do here is just a form of plain concat or union.
# union
{'1'} | {2} # MAYBE OK
reveal_type({'1'} | {2}) # => Set[Union[str, int]]
If we look at Sets as just containers without some
properties, we could accept it to construct mixed
type Sets using 'union'. I think it is okay for Python,
the name union makes it meaningful, but I maybe never did
that in practice.
Since it adds to the type it is also likely that
the following part of the program catches mistakes.
(But lists don't allow that [1] + ['2'] although they're really
arbitrary containers. Except my PR #3183.)
Activity
srittau commentedon Sep 3, 2019
Could you prepare an experimental PR (maybe after #3181 is merged), so interested parties can try this against real world code bases? This way we could better evaluate the impact this change would have (good or bad).
kaste commentedon Sep 5, 2019
We have
set,frozenset,AbstractSet,MutableSet, andItemsViewandKeysView. Should a PR make all of them consistent?srittau commentedon Sep 5, 2019
That would make sense to me.
kaste commentedon Sep 6, 2019
I think I need help here. Current situation in master is. Given:
unionis defined "restrictive"T -> T -> Tand__or__is "additive permissive"T -> S -> Union[T, S]In contrast
intersectionand__and__are permissiveT -> Any -> T.These are the two type variants we see for
Set. Do we want consistency between the methods and the dunder constructors?If I make
intersection"restrictive"T -> T -> Tmypy will rejectstrs & intsbut we break the lawints & floats == floats & intsbecause mypy surprisingly accepts the latter. It should reject both. On the other side theunionmethod already behaves like that.We could also go pragmatic:
unionandsymmetric_differenceas "additive"T -> S -> Union[T, S],intersectionasT -> S -> St.i. returning theRight. Whenever we change the type we have at least a good chance the following code will catch an error. No change fordifferencecomes to my mind though.