Repository navigation
An Intersection type? #18
Description
Activity
(In README.text, Łukasz suggested to use Any[] instead of Union[] so that All[] can be used as Intersection[]. Feels a bit cute to me.)
Having intersections is important since we don't have structural sub-classing and protocols will likely not be composable with ABCs.
Any/All is not only cute, it's also shorter to type and more obvious to the reader :)
Łukasz, can you show a few examples of how Any/All would be used? Your README note was rather cryptic. I agree Intersection is verbose, but it sounds like a minor use case, and I don't want to lose unparameterized Any as the top (or is that bottom? :-) of the type tree/graph.
I think this would be occasionally useful, but clearly this would be a minor feature. I vote for leaving this out for now and waiting until we have seen some real-world use cases that would benefit from intersection types.
Reacted by Tyler C Laprade, CFAAgreed. Let's skip it for now then.
What I proposed is alternative names: Union becomes Any, Intersection becomes All. typevar(values=) could become OneOf, with the bracket syntax, which would be more consistent.
Examples:
AnyStr = OneOf[bytes, str] def memcache_get(key:AnyStr) -> Optional[AnyStr]: ... OneOrMany = OneOf[AnyStr, List[AnyStr]] def memcache_set(key:OneOrMany, value:OneOrMany) -> int: ... # but: def retry(callback:Callable[AnyArgs, Any[int, None]], timeout:Any[int, None]=None, retries=Any[int, None]=None) -> None: ... # equiv: OptionalInt = Any[int, None] def retry(callback:Callable[AnyArgs, OptionalInt], timeout:OptionalInt, retries:OptionalInt) -> None: ...Note that
Allprovides a form of structural typing:# The following absurd function uses retryable.__len__ and retryable.__call__ def retry(retryable:All[Sized, Callable]): while len(retryable): retryable()Of course, we could provide more sensible ABCs for "file-like" objects, etc.
I deal with cache invalidation for a living, naming things and off-by-one errors are just a hobby.
Sorry, I don't like any of that. Can we just drop it?
- Using
Any[t1, t2, ...]instead ofUnion[t1, t2, ...]would be confusing if we kept plainAnyfor its current meaning (it's consistent with everything). - Using
T = OneOf[t1, t2, ...]instead ofTypeVar('T', t1, t2, ...)hides the fact that it is a type variable (and all arguments must match). E.g.def foo(a1: AnyStr, a2: AnyStr):is very different fromdef foo(a1: Union[str, bytes], a2: Union[str, bytes]):. - In An Intersection type? #18 we already decided not to define an intersection type for now. And in Protocols (a.k.a. structural subtyping) #11 we decided not to define protocols for now. So I think they shouldn't be "smuggled back in" this way.
- Type variables should not use brackets, they should use parentheses. I've explained this already (What's the proper way to spell the type of a callable? #5).
Reacted by Tyler C Laprade, CFA- Using
OK, that covers it. No Intersection for now, names stay as they were.
Its been a number of years since this thread was first opened, so I wanted to bump on it. From my perspective, the lack of an intersection type is one of the key flaws of the python type system at current, and its introduction would be majorly beneficial.
There is an open issue about this, #213.
+1 comments are better done via emoji than by tagging people. In any case, #213 is the issue tracking this feature.
- locked and limited conversation to collaborators
on May 30, 2023
Sometimes you want to say that an argument must follow two or more different protocols. For example, you might want to state that an argument must be an Iterable and a Container (for example, it could be a Set, a Mapping or a Sequence). It would be nice if this could be spelled like this: