Update typing to Python 3.9 and fix typos

[hunterhogan]

Improve type hints throughout the codebase to align with Python 3.9 standards and correct minor typographical errors.

[madig]

Is this all output of a tool? Did you change something by hand? Main is requiring Py >= 3.10 now, so there might be more to update.

[hunterhogan]

Probably, on each file:

1. run pyupgrade --p310-plus.
2. With VS Code and Code Spell, add words to the workspace dictionary, code-spell-dictionary-workspace.txt, then correct typos.
3. In the "Workspace" for this package, I disabled things like Ruff, which I normally use, and enabled the tools y'all are using, like Black. So, I probably applied those tools, too.

I don't remember what originally motivated me to make a change, but the above list is the most likely reason for changes in 26 files.

I'm still confused by the terminology in the world of font applications, so I would only have made changes to code if the tools (e.g., type checkers) said it was correct.

[hunterhogan]

Thank you for your patience. I apologize for structuring this in such a way that it creates extra work for you.

If you are willing, we could use this PR to teach me better processes. I am willing to redo the work in this PR if you can tell me how to structure the PR, or multiple PR, to reduce the amount of work other people have to do.

Of course, that would ironically cause you to do a lot more work.

[hunterhogan]

Oh man, I only just now saw the 3.9 and 3.10 difference. 🤦 🤦

I will reread all of this when my brain is more cooperative.

[madig]

No worries, I'm not allergic to work, as long as someone makes it easy for me :)

I generally like PRs like this, but again, it really helps if you could split each action you take into separate commits, so I can go "Okay, this commit updates all annotations, the next one fixes typos, ...", allowing me to focus on one thing at a time. Reducing cognitive load actually makes me work faster, even if there are more commits. It also makes it easier to redo a step, like upgrading to 3.10 syntax, while leaving the other, already reviewed commits alone.

For example, to change just the syntax update commit, you can use Git's interactive rebase and mark a commit to stop at and fix up. You'd just run the 3.10 update, add the changes and continue rebasing. The result would be three commits where the first one now updates syntax to 3.10 instead of 3.9, while leaving the other commits alone.

BTW, you can also list words or phrases here that confuse you, we can clear those up :)

[hunterhogan]

"Okay, this commit updates all annotations, the next one fixes typos, ..."

^^^ THIS is a huge revelation for me. It never occurred to me that anyone would use git/commits like this. Earlier, I misunderstood your suggestion to mean creating different Pull Requests, which I thought would create new problems. But this makes sense.

Ok, to me, this is a great, low-risk, low-pressure opportunity for me to learn more about process, so if you are willing to continue coaching me about how I am constructing the PR, I would love to start over.

(When I taught Sys-/Net-admin/MCSE, I strongly emphasized process; as a lawyer/legal-philosopher, I strongly believe in process-as-justice. Hence, my absurd excitement about learning the process of gittnʼ.)

Git's interactive rebase and mark a commit to stop at and fix up. You'd just run the 3.10 update, add the changes and continue rebasing.

I don't really understand what this means, but it's not your fault.

Git is the worst widely used software for consumer microprocessors ever made. I cut my teeth on a VIC-20, I worked for nine years in IT, and (especially since I was a trial lawyer) I can/will support that claim against anyone. Nevertheless, git is more ubiquitous than herpes (80% of adults worldwide), so I must use it.

The VS Code SCM panel makes things easier for me, though. I've only had bad experiences when an LLM told me to use git rebase, but I've had success with "Undo last commit", which might mean git reset --soft HEAD~. (<-- I'm pretty sure that was a marketing campaign for Viagra).

In any case, my plan is:

1. Cause hunterhogan:typing to match the current fonttools:main.
2. Create incremental commits that are activity-based, Disney-themed, or both.
3. Get madig git guidance.

---

BTW, you can also list words or phrases here that confuse you, we can clear those up :)

pen, layer, subroutinizationingly, OS/2 has been dead for 25+ years, ttf doesn't always mean ttf, ttf/otf/cff/cff1/cff2/type1/type2/ufo/hbo/gmo/ttc/otc/otc-named-ttc/svc, and basically every term specific to digital font creation. I thought, "I'm not trying to create a font: I just want to mash up characters from different fonts. That shouldn't be too hard." I was wrong.

I'll focus on learning how to be a better collaborator for now. :)

[hunterhogan]

Done. If you have time, of the things I did this time, tell me which things I should do in the future and which things I could improve.

[madig]

I don't really understand what this means, but it's not your fault.

There's more than one way to do this, have a look at e.g.

• https://www.youtube.com/watch?v=6k7OBUnCa7Q
• or https://www.youtube.com/watch?v=r8bmF5UpZbY

An interactive rebase allows you to also "edit" a commit (not in the videos), which I can't find a video for. Git is unintutive, but practice makes better.

pen, layer, subroutinizationingly, OS/2 has been dead for 25+ years, ttf doesn't always mean ttf, ttf/otf/cff/cff1/cff2/type1/type2/ufo/hbo/gmo/ttc/otc/otc-named-ttc/svc, and basically every term specific to digital font creation.

OS/2 is a vestige of the times when that praticular table was specified for TrueType. Backwards compatibility dictates you can't change the name. A pen is a abstraction that lets you draw geometry no matter what the backing object is. There's lots of different glyph-like objects in font land, and a pen lets you draw into any of them with one API. Subroutinization is specific to CFF(2) fonts, as CFF(2) is basically the PostScript drawing model stuffed into fonts. Glyphs are drawn via commands, and there are no TrueType-like components that let you reuse shapes, so you try to extract common drawing commands into separate shadow glyphs for reuse (subroutinize) in other glyphs, to reduce file size. The other things you may look up in the OpenType spec or by asking AI.

Now, the commits are a bit messy.

1. The first 3 commits are basically to restore the state of main. You can just drop them when rebasing interactively on main (look it up).
2. Please make a commit for each tool you run
3. Merge the two commits for pyupgrade into one as per the videos above

[hunterhogan]

Uh, I guess that an unintended side effect of one of my action closed this.