Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[spec] overload subtyping rules are too strict.

Ouverte
  • Quelque chose ne va pas ?
#2,021 3 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
python
Domaine
compilers

Piste de recherche

Commencez par les règles de sous-typage des overloads dans la section consacrée aux callables de la spécification de typing et examinez la discussion associée dans typing/discussions/1782. Comparez les règles énoncées avec l’exemple IntScalarOurs et IntScalarTheirs, puis déterminez si la spécification nécessite une révision de principe ou une règle clarifiée de condition suffisante.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

topic: other

The typing spec states that, when A and B are potentially overloaded methods

If a callable B is overloaded with two or more signatures, it is assignable to callable A if at least one of the overloaded signatures in B is assignable to A

If a callable A is overloaded with two or more signatures, callable B is assignable to A if B is assignable to all of the signatures in A

However, this definition seems to be too strict. Consider the following example:

from typing import Protocol, Self, overload

class IntScalarOurs(Protocol):
    def __add__(self, other: int | Self, /) -> Self: ...

class IntScalarTheirs(Protocol):
    @overload
    def __add__(self, other: int, /) -> Self: ...
    @overload
    def __add__(self, other: Self, /) -> Self: ...

These two protocols specify the exact same runtime behavior. Yet, following the rules of the spec, IntScalarOurs is assignable to IntScalarTheirs, but IntScalarTheirs is not assignable to IntScalarOurs.

Case 1: A=IntScalarOurs, B=IntScalarTheirs.

If a callable B is overloaded with two or more signatures, it is assignable to callable A if at least one of the overloaded signatures in B is assignable to A

  • Is (self, int) -> Self assignable to (self, int | Self) -> Self? No, because int is not a supertype of int | Self (contravariance)
  • Is (self, Self) -> Self assignable to (self, int | Self) -> Self? No, because Self is not a supertype of int | Self (contravariance)

Thus, IntScalarTheirs is not assignable to IntScalarOurs.

Case 2: A=IntScalarTheirs, B=IntScalarOurs.

If a callable A is overloaded with two or more signatures, callable B is assignable to A if B is assignable to all of the signatures in A

  • Is (self, int | Self) -> Self assignable to (self, int) -> Self? Yes.
  • Is (self, int | Self) -> Self assignable to (self, Self) -> Self? Yes.

Thus, IntScalarOurs is assignable to IntScalarTheirs.

From a pure set-theoretic POV, it seems that subtyping functions should follow a very simply rule based on the domain.

$f <: g$ if and only if $\text{dom}(f) ⊇ \text{dom}(g)$ and $f(x) <: g(x)$ for all $x∈\text{dom}(g)$

What is currently specced appears to be a lemma for a sufficient condition, but not a necessary one.
Individual type-checkers can of course use such lemmas if the general case is too difficult to check/implement (and communicate that to their users), but shouldn't the spec be biased towards the theoretically principled point of view, when applicable?

Related Discussions

https://github.com/python/typing/discussions/1782

Langage dominant
Python
Étoiles
1.8k
Forks
302
Merge moyen
4 h 38 min
PR mergées (30 j)
6

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de python/typing

Toutes les issues de python/typing

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.