Three Dollar Quill

I ended up trying out mutmut. It's mostly a more polished and streamlined experience than Cosmic Ray was, although it did run into some areas where it should have timed out, but instead just stayed stuck in a loop. I had to manually whitelist the lines responsible, to remove those cases. All of this was pretty interesting, but when I looked over some of the mutations, I saw that they were to code that only matters in terms of type-checking.

Which means that if I want reasonable tests that catch those mutants, I need to add type-checking. Which means that I need to finish the plugin. Which means that I need to re-implement Product types.

Ugh, I don't want to do this right now, and to try to explain why I at least don't want to do it tonight, I'll plan out what needs to be supported.

There are three groups of methods: repr methods, equality methods, and ordering methods. These methods are in one of three states: unimplemented, generated, and custom-implemented. I tried to work out some elaborate interrelationships between order and equality methods, beyond the fact the generating order requires successfully generating equality, but I think that was a bad idea, and I'm just going to say:

• Unimplemented means the methods aren't in the class namespace, but something is probably visible due to the class hierarchy.
• Generated methods do not use super(), and act as pass-through when called from an "incompatible" class. (This can be implemented by checking the type of self against the class they belong to.)
• Custom methods can use super(), and are visible when called from a "compatible" class: one in which the same method group is custom, and the fields list matches exactly. (Just names, or order as well. Not sure, leaning towards order.)

A method group can't change its state after the subclass is initialized. This means the following:

• It is an error to assign over a generated method.
• It is an error to assign to an unimplemented method. (This may get relaxed, but I want to be cautious.)
• It is not an error to assign to a custom method, but some manner of processing is needed.
• It is acceptable to assign a dummy value to a method to make it custom, and later inject the actual implementation.
• Deleting is probably not a thing that can be done, unless the custom and unimplemented groups can be unified.

It might be that repr and equality are tri-state, and order is a boolean. Maybe it's acceptable to switch between custom and unimplemented only if the associated option is False.

I feel like it would be folly to move forward on this without doing more design work, so I guess that's what I've got to do next.

I'm really unlikely to get this right without sleep, so I should probably get on that soonish. Good night.