Skip to content
/ fixo Public

Semi-automatic rule-based editing of Python code bases

License

Notifications You must be signed in to change notification settings

rec/fixo

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

88 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

fixo

Goals.

  • Light weight, semi-automatic rule-based tool to add type annotations to Python code bases.

  • Apply rule-based edits, and allow the user to pick and choose which edits to accept.

  • Edits are not represented as raw diffs, but as semantic changes to the Python source, which are far more likely to be stable through intermediate changes in the code.

  • The rules to match code and to perform edits can easily be user code.

  • Less than 1k lines of code with testing.

Design sketch

The input to the program would be the output of some other diagnostic tool, like pyrefly or mypy, outputs that are divided into messages, one complete message from the diagnostic tool to the user. In pyrefly it can just be a single line of text.

A message has a file name, a symbol name, and a line number, a column number for the start and end of position in the file.

For each message in the input, and for each rule that that message matches, the rule creates a proposed edit to the message's file, and then writes that edit as a line of JSON into the "edits file"

The user chooses selects which edits to use, initially by just editing the edits file, and soon with a little terminal interface that displays the proposed change in context of the Python source file.

Then the edits file is applied to the code base all at once.

How to write it?

Four main parts need to be written:

  1. Parsing the inputs into messages
  2. Matching messages against rules
  3. Creating an edit from a rule and a matching message
  4. Performing an edit

The hard part: it must easy be for developers to create and perform edits without knowing how to parse a Python file

As of October 1

All the fundamental classes exist and some tests of the trickiest parts of their functionality too - it mostly corresponds to the above.

Now we embark on three specific rules to apply to PyTorch

  1. Add a bool return type annotation to methods and functions that start with _?(is|has)_
  2. Add a bool type annotation to parameters that start with (is|has)_
  3. Add a torch.Tensor type annotation to function (but not method) parameters named self

About

Semi-automatic rule-based editing of Python code bases

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages