python / python/typing

Allow returning `AnyOf` rather than `Any` for amiguous overloads.

Open
#2,196 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

topic: feature topic: typing spec
Dominant language
Python
Stars
1.8k
Forks
302
Avg merge
23h
Merged PRs (30d)
8

Description

Currently, the typing spec for overloads, step 5, states that

Once this filtering process is applied for all arguments, examine the return types of the remaining overloads. If these return types include type variables, they should be replaced with their solved types. If the resulting return types for all remaining overloads are equivalent, proceed to step 6.

If the return types are not equivalent, overload matching is ambiguous. In this case, assume a return type of Any and stop.

However, couldn't this rule be relaxed to returning the union of the return type of all matching overloads? For instance, consider this example derived from a real world use case (numpy scalar ops)

from typing import Any, overload, assert_type

class A[T]:  # covariant
    def get(self) -> T: ...

@overload
def op(l: A[None], r: A[None]) -> A[None]: ...
@overload
def op(l: A[None], r: A[Any]) -> A[None]: ...
@overload
def op(l: A[Any], r: A[None]) -> A[None]: ...
@overload
def op(l: A[Any], r: A[Any]) -> A[Any]: ...

def test(x: A[None], y: A[Any]) -> None:
    assert_type(op(x, x), A[None])  # spec: ✅️ 
    assert_type(op(x, y), A[None])  # spec: ✅️
    assert_type(op(y, x), A[None])  # spec: ✅️
    assert_type(op(y, y), A[Any] | A[None])     # spec: ❌️ (expected Any)

According to the rule stated above, op(A[Any], A[Any]) should be inferred to as Any, because the overloads are ambious and A[Any] is not equivalent to A[None] as not all materializations of A[Any] can be assigned to A[None].

However inferring Any loses deducible information: we know that no matter what, the return type must be an A. So in principle the return type should be A[Any] | A[None], because if either the left argument or the right argument materializes to A[None], then we get A[None] and otherwise if they materialize to something else we get A[Any].

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with overload specification step 5 and the glossary definition of equivalent linked in the issue. Analyze the A[Any] and A[None] example and determine whether ambiguous overloads should retain a union rather than become Any. Done means the typing specification has a decided, documented rule for this case and the example reflects that rule.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.