An Intersection type? about typing HOT 11 CLOSED

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.

from typing.

Sorry, I don't like any of that. Can we just drop it?

• Using Any[t1, t2, ...] instead of Union[t1, t2, ...] would be confusing if we kept plain Any for its current meaning (it's consistent with everything).
• Using T = OneOf[t1, t2, ...] instead of TypeVar('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 from def foo(a1: Union[str, bytes], a2: Union[str, bytes]):.
• In #18 we already decided not to define an intersection type for now. And in #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 (#5).

from typing.

(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.)

from typing.

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 :)

from typing.

Ł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.

from typing.

Agreed. Let's skip it for now then.

from typing.

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 All provides 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.

from typing.

OK, that covers it. No Intersection for now, names stay as they were.

from typing.

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.

@gvanrossum

from typing.

There is an open issue about this, #213.

from typing.

+1 comments are better done via emoji than by tagging people. In any case, #213 is the issue tracking this feature.

from typing.