python / python/mypy

More ideas about plugin system

Open
#5,905 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

needs discussion priority-1-normal topic-plugins
Dominant language
Python
Stars
20.6k
Forks
3.3k
PR merge metrics
PR metrics pending

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.)

Contributor guide

Open the contributing guide

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 by reading the plugin-related logic in checkmember.py and checker.py, then review the planned semanal.py refactoring and the linked issue #5409. The issue lists several design questions about semantic-analysis and type-checking hooks, but it does not define a single change or a concrete done criterion.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.