python / python/mypy

More ideas about plugin system

Ouverte
#5,905 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

needs discussion priority-1-normal topic-plugins
Langage dominant
Python
Étoiles
20.6k
Forks
3.3k
Métriques de merge des PR
Métriques de PR en attente

Description

After some time spent on writing SQLAlchemy plugin and a discussion with @JukkaL here are some comments and ideas about our plugin :

  • Currently, member signature hook is not called on __init__ and __new__. Current workaround is to use function hook, but it is still painful. The solution would require moving type_object_type() (and maybe a bunch of other helpers) from checkmember.py to a separate module (which is probably a good idea on its own). We can also move some helpers from checker.py related to type objects to the same module.

  • During semantic analysis types of expressions are not known. This poses a problem in attrs and even more in SQLAlchemy: When generating an __init__ method for a model, plugin needs to figure out what is a type of attributes from definitions like name = Column(String(40)). Currently I do this using some heuristics that works in 95% of cases (and so does attrs plugin), but a better solution is probably to just store names of "magic" classes (SQLAlchemy models, dataclasses etc.) in the plugin state, add a dummy __init__ to symbol table, and defer figuring out actual type to the method signature hook that is called in type checking (depends on fixing previous bullet).

  • It is better to move calling semantic analysis hooks to the very end, or (probably even better) just allow them to defer current target (but this is currently not possible).

  • We should not allow most type operations in semantic analysis hooks (we can't enforce it, but should at least document it clearly). Some operations are still OK (like map_instance_to_supertype() or erase_type()).

  • The type checking hooks should also be able to defer current target using a special return value or an exception (e.g. __init__ signature hook in the SQLAlchemy example above if one would use a user-defined type in an import cycle).

Probably, most (or all) of decisions should be made after the upcoming semanal.py refactoring.

(Also function hook is inconvenient, but @gvanrossum already mentioned this in https://github.com/python/mypy/issues/5409 that has a bunch of good ideas about improving plugin system.)

Guide de contribution

Ouvrir le guide de contribution

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.

Piste de recherche

Commencez par lire la logique liée aux plugins dans checkmember.py et checker.py, puis examinez la refactorisation prévue de semanal.py et l’issue #5409 associée. L’issue présente plusieurs questions de conception concernant les hooks d’analyse sémantique et de vérification des types, mais elle ne définit ni un changement unique ni un critère concret d’achèvement.

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

Évaluation

Stack technique
python
Domaine
compilers
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

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