Three Dollar Quill

• Wednesday: I was mildly freaked out about the election. I also talked about the Fate Roll.
• Thursday: I wasn't up for much, so I rewrote the code and disabled a bunch of tests.
• Friday: I explained the changes, and decided they were a net positive.
• Saturday: I made an update suggested by my previous changes.
• Sunday: I fixed up the tests I disabled.
• Monday: I decided to revisit my effort ten and a half months ago, to update or fork or do something to punq.

Next week, I'm going to have to figure out how best to continue with the punq fork I'm developing. Adding typing to the current state of it is... not happening. I guess I should be working on tests, or maybe just... I don't need to keep using limit-coverage for now. So, let's comment that out of the noxfile and see what kind of raw coverage numbers we get... All right, I can confirm that, in spite of what punq's coverage badge says, it gets full coverage.

All right, remembering one of the directions I wanted to go all that time ago, I kind of wanted to make it canonicalize on string representations of types, but being aware of aliases.

Let me see if I remember the logic.

From the annotation side, given a string annotation in the context of a module, I want to assume that the name before the final dot evaluates to a module, and that module contains the remainder of the name, and that if the __name__ attribute of the class matches the name, then the canonical name is the __qualname__ of the class, and that otherwise, the canonical name is the __name__ of the module and the original RHS.

From the registration side, passing a class is shorthand for passing its __qualname__ (and probably similarly for resolution). I want to avoid going too far with stack introspection, so I'll probably just want a helper function that basically takes (module, alias) to f"{module.__name__}.{alias}" and is more compact.

I think I can work from here. I've got a few more ideas that are a bit less fleshed out, but also less fundamental, so I'm okay leaving them sketchy for now.

Quick notes for my future self:

• Rely on the ast module to figure out where to look for the module path.
• I'm not sure how to handle subscripts, but I'm pretty sure the overall stuff that I can conceivably care about matching is like (<module name>\.)*<class name>(\[<args>])?. In other words, if it's an index, then probably discard the subscript, expect either a bare identifier, or an attribute access, in which the right hand side is a bare identifier, and the left-hand side is evaluated in the context of the current module to change the current module for the purposes of evaluating and analyzing the right-hand side.
• Allow some minor "inconsistencies" in the interpretation of the "just the class" registration shortcut.
• Walk the mro to figure out which module to resolve the __init__ annotations from the context of. First class in the mro where the __init__ shows up in the __dict__ is the place to look for the context.

Okay, that's enough poking at the code and design. Done for now.