Skip to content

Commit e835221

Browse files
committed
Removed section on overlapping overloads. We're struggling to get agreement on the proper behavior, and this section is lower priority. We can revisit in the future if there's a desire to do so.
1 parent f4293e8 commit e835221

File tree

2 files changed

+0
-92
lines changed

2 files changed

+0
-92
lines changed

conformance/tests/overloads_overlap.py

Lines changed: 0 additions & 40 deletions
This file was deleted.

docs/spec/overload.rst

Lines changed: 0 additions & 52 deletions
Original file line numberDiff line numberDiff line change
@@ -185,58 +185,6 @@ implementation body, the use of ``async def``, and the presence of additional
185185
decorators.
186186

187187

188-
Overlapping overloads
189-
^^^^^^^^^^^^^^^^^^^^^
190-
191-
If two overloads can accept the same set of arguments, they are said
192-
to "partially overlap". If two overloads partially overlap, the return type
193-
of the former overload should be assignable to the return type of the
194-
latter overload. If this condition doesn't hold, it is indicative of a
195-
programming error and should be reported by type checkers. The purpose of
196-
this check is to prevent unsoundness of this form::
197-
198-
@overload
199-
def is_one(x: Literal[1]) -> Literal[True]: ...
200-
@overload
201-
def is_one(x: int) -> Literal[False]: ...
202-
203-
reveal_type(is_one(int(1))) # Reveals Literal[False], but True at runtime
204-
205-
Type checkers may exempt certain magic methods from the above check
206-
for conditions that are mandated by their usage in the runtime. For example,
207-
the ``__get__`` method of a descriptor is often defined using overloads
208-
that would partially overlap if the above rule is enforced.
209-
210-
Type checkers may ignore the possibility of multiple inheritance or
211-
intersections involving structural types for purposes of computing overlap.
212-
In the following example, classes ``A`` and ``B`` could theoretically overlap
213-
because there could be a common type ``C`` that derives from both ``A`` and
214-
``B``, but type checkers may choose not to flag this as an overlapping
215-
overload::
216-
217-
class A: ...
218-
class B: ...
219-
220-
@overload
221-
def func(x: A) -> int: ...
222-
@overload
223-
def func(x: B) -> str: ...
224-
225-
If all possible sets of arguments accepted by an overload are also always
226-
accepted by an earlier overload, the two overloads are said to "fully overlap".
227-
In this case, the latter overload will never be used. This condition
228-
is indicative of a programming error and should be reported by type
229-
checkers::
230-
231-
# These overloads fully overlap because the first overload
232-
# accepts all arguments accepted by the second overload.
233-
234-
@overload
235-
def func[T](x: T) -> T: ...
236-
@overload
237-
def func(x: int) -> int: ...
238-
239-
240188
Overload call evaluation
241189
^^^^^^^^^^^^^^^^^^^^^^^^
242190

0 commit comments

Comments
 (0)