afdko icon indicating copy to clipboard operation
afdko copied to clipboard

Add typing to otfautohint

Open simoncozens opened this issue 2 years ago • 11 comments

Description

otfautohint is a complex piece of code, and it's easy to get lost; it's even easier to make mistakes. Having typing information available makes it easier to catch such mistakes, and allows editors with Python type inferencing (Visual Code with pylance, Sublime Text with pyright, etc.) to provide type hints for variables and methods. This in turn helps to find typos, dead code, and so on.

Checklist:

  • [X] I have followed the Contribution Guidelines
  • [ ] ~I have added test code and data to prove that my code functions correctly~ (N/A)
  • [X] I have verified that new and existing tests pass locally with my changes
  • [X] I have performed a self-review of my own code
  • [X] I have commented my code, particularly in hard-to-understand areas
  • [ ] ~I have made corresponding changes to the documentation~ (N/A)

simoncozens avatar Oct 18 '23 21:10 simoncozens

As you're probably realizing this has a lot of formatting related problems (flake8), some of which are due to edits for line length that you've removed.

skef avatar Oct 18 '23 21:10 skef

@simoncozens thanks for this contribution. It looks like there are a number of linter failures that are blocking the tests from running. I recommend that you run flake8 using the config from this repo, fix all reported issues, and resubmit. Once we get the linter + tests green we will have a closer review and see about getting it merged.

josh-hadley avatar Oct 18 '23 21:10 josh-hadley

Yeah, sorry, I was assuming the code formatting was black/PEP8 so my editor runs black on save to keep things tidy. I'll try and put things back into your preferred style.

simoncozens avatar Oct 18 '23 21:10 simoncozens

I think I would prefer a submission with the substantive changes and then (perhaps) a different submission with the large amount of stylistic changes. Or perhaps just skip the latter? Best to either mesh one's contributions with the existing style or talk in advance about what you want to change and why.

Edit: Ninja-ed.

skef avatar Oct 18 '23 21:10 skef

@josh-hadley Merging this would presumably require additional pytype github checks, so that notations like # pytype: disable=attribute-error won't just rot.

skef avatar Oct 18 '23 21:10 skef

To be honest, it doesn't currently work with pytype. I started working with pytype, and as I added annotations I found myself in situations where a method returned an instance of its own class, which needs the Self type, and pytype doesn't currently support that. So I switched to mypy. In a couple of cases mypy doesn't like the Self return value, but it does a better job than pytype (and continues running, whereas pytype just stops and refuses to go on).

simoncozens avatar Oct 18 '23 22:10 simoncozens

Coverage tests are sad because apparently you can't use weakref.ReferenceType as a generic in Python 3.8.

simoncozens avatar Oct 19 '23 09:10 simoncozens

One reason we ported psautohint to python was the hope that it could be modified by the broader community, in comparison to the C code which was only ever worked on by a small group of Adobe-internal folks while squinting hard and crossing their fingers.

This PR is both an external contribution and an effort to make further contributions easier, so in that sense it's what we want and were hoping for.

Still, there is a basic concern about keeping these annotations from rotting. Some users will have environments that will make good use of the typing. Others will just be editing the files and running the tests and may have no idea what this stuff is or, if they do, how to change the annotations as the code changes.

Obviously some sort of verifier that can be run as part of the GitHub checks would be ideal, but it sounds like pytype can't do that and mypy might or might not be able to.

Do you have thoughts on this? Basically, how to maintain types in Python assuming a wide variety of users with different levels of experience and tooling?

Also: Keep in mind that we haven't been doing this internally, so it make take a while just to digest the implications of typed Python on our end.

skef avatar Oct 19 '23 14:10 skef

FWIW annotations are pretty useless unless they are actually checked by a typechecker

anthrotype avatar Oct 19 '23 14:10 anthrotype

ok, well.. self-documentation sure, but they then tend to rot as @skef noted.

anthrotype avatar Oct 19 '23 14:10 anthrotype

Obviously some sort of verifier that can be run as part of the GitHub checks would be ideal, but it sounds like pytype can't do that and mypy might or might not be able to.

We can certainly get mypy set up in the CI, and add a disable comment to turn off the Self checks.

simoncozens avatar Oct 19 '23 16:10 simoncozens