Make support for type comments optional
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
- Documentation
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- python
- Domaine
- documentation
Piste de recherche
Lisez le traitement des commentaires de type dans la spécification de typing ainsi que PEP 484 et PEP 526, puis examinez la discussion précédente JelleZijlstra/typing-spec#1. La tâche est terminée lorsque la spécification permet aux vérificateurs de types d’omettre la prise en charge ordinaire des commentaires de type, tout en conservant l’exigence concernant les commentaires # type: ignore et en expliquant les recommandations de compatibilité.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
PEP 484 (and therefore the current typing spec) implies that type checkers must support the old "type comment" syntax. However, this syntax is unnecessary since Python 3.6 and PEP 526, so there is little reason for new type checkers to support it.
I think we should no longer make support for type comments mandatory. We can keep describing the intended semantics of type comments, but say that type checkers are free to drop support for them. Code that is intended to work across type checkers (e.g., library stubs) should not use them.
PEP 484 (and therefore this spec) imply that type checkers must support the old "type comment" syntax. However, this syntax is unnecessary since Python 3.6 and PEP 526, so there is little reason for new type checkers to support it.
I think we should no longer make support for type comments mandatory. We can keep describing the intended semantics of type comments, but say that type checkers are free to drop support for them. Code that is intended to work across type checkers (e.g., library stubs) should not use them.
(Note that this does not include # type: ignore comments. Those are still useful and should continue to work.)
This isn't urgent so I'll likely not pursue this very soon, but I'm filing this issue to keep track of the idea. I previously filed JelleZijlstra/typing-spec#1, where one person spoke up because they still like type comments, but I'm planning to archive that repo.
- Langage dominant
- Python
- Étoiles
- 1.8k
- Forks
- 302
- Merge moyen
- 23 h
- PR mergées (30 j)
- 8
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de python/typing
-
topic: typing spec
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
-
topic: typing spec
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
topic: documentation
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
-
topic: documentation
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
-
topic: conformance tests topic: typing spec
Difficulté 3/5 1-2 jours Accessibilité débutants 72/100
Toutes les issues de python/typing
Issues similaires
-
agent-ready documentation needs-triage
Difficulté 1/5 1-3 heures Accessibilité débutants 88/100
-
documentation
Difficulté 1/5 Moins d'une heure Accessibilité débutants 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" Ouverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
-
Add https://search.jeremyh.xyz/ Ouverteinstance instance add
Difficulté 1/5 Moins d'une heure Accessibilité débutants 72/100
searxng/searx-instances#939 · 1 commentaire ·
-
area-deployment area-integrations triage:bot-seen
Difficulté 2/5 Une demi-journée Accessibilité débutants 86/100