The assertion rewriting is a really cool idea! Cool to see this still being developed. Some comments:

• Since the minimum python version for this version of check50 appears to be >= 3.10 (per the match statements), check50/contextmanagers.py could be deleted. It contains an implementation of contextlib.nullcontext which was 3.7+ and I think we wanted to support Python 3.6 at the time.

• Out of curiosity, how does the assertion rewriter intersect with check50.import_checks? Do imported files get rewritten as well? Just looking at the code it seems like no, which seems highly unintuitive (e.g. if mario/less utilized asserts and had rewriting enabled, mario/more which imports the checks from less would not have its assertions rewritten, and so you'd get errors instead of failures on failed asserts. Am I showing my age with these pset names?).

  Even if I'm not importing checks from another directory, if I split my checks within a directory up into multiple files and then import them into my __init__.py, do the assertions there get rewritten? I think similarly the answer is "no". That case is probably not as important to cover since the common case probably is all checks in one file, but still. Obviously you wouldn't want to try to recurse over every import in __init__.py but perhaps some generalization of check50.import_checks could cover this case? (e.g. foo = check50.import_checks("./foo.py") would import foo.py and call the assertion rewriter if appropriate. Right now, import_checks I think is specialized to directories.)

  Edit: This is still annoyingly fragile since someone might (very sensibly) expect normal pythonic imports to Just Work. Maybe a limited recursion exclusively over imports within the package could cover this case. Meanwhile simply updating check50.import_checks to run the assertion rewriter on the module it imports should suffice to cover importing checks from another directory.

• Edit2: this shouldn't block merging, but at some point it might be worth considering whether the attrs dependency can be removed. Since this was originally implemented, Python now has dataclasses in the standard library which are a simplified version of attrs. If the more advanced features of attrs aren't being used, then the dependency might not be needed at all.