Discussion: How to handle type annotations

[Austin Bingham]

As part of the language and the AST, type annotations are potentially subject to annotation. At the same time, it seems that nearly all mutations to type annotations will result in equivalent mutants; that is, they rarely have an effect that's detectable at runtime. There are, however, situations where mutations to type annotations can have a runtime effect; one example was demonstrated to me by @rob-smallshire.

Given all of this, we need to decide how CR will deal with type annotations.

Ignore them completely

One possibility is to simply ignore them completely. We could build this into the low-level AST visitor code, thereby treating it as a policy decision for the project. This has the downside of disallowing mutation of annotations in the cases where it might matter. On the upside, it's something we could change our mind about later.

Disable them by default but allow selected mutations

We could decide that mutation of annotations is disabled by default but that the user can select instances to be mutated. This would lend itself to some sort of interceptor-based approach as has been explored by @Alcolo47.

Enable them by default but allow selected disabling of mutation

This is just the complement of the last idea. It seems unlikely (to me) to be the right approach, but it's a possibility.

Others?

Maybe there are clever ways to manage these. Maybe, in fact, there are ways to integrate type annotations into a test suite, e.g. by running mypy over the code to look for violations, thereby making CR mutation of annotations more meaningful.

[Anders Hovmöller]

What is that example?

[Austin Bingham]

Unfortunately is from a client project that we can't (as far as I know) share, but it has to do with introspecting the type annotation at runtime in order to facilitate interfacing with another language (Java, I think). Of all the ways we considered to do this, it was the cleanest and most unsurprising...when trying to work with static languages, be a little static ourselves.

…

On Wed, Oct 9, 2019 at 6:41 PM Anders Hovmöller ***@***.***> wrote: What is that example? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#479?email_source=notifications&email_token=AAATK6EDUQ7TXEZ5KDPWGKDQNYJVFA5CNFSM4I7CNZQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAYW2RQ#issuecomment-540110150>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAATK6F4PES7ZBYD3JOVVE3QNYJVFANCNFSM4I7CNZQA> .

[Anders Hovmöller]

Ah. Yea that description is enough for me to understand the issue. We have something similar at work where we generate Elm code for data structure serialization between front end and backend that now uses dataclasses.

[finswimmer]

Hey,

would be cool to see any progress in this topic 😃

I would argue that in most cases mutating type annotations doesn't lead to any valuable insights. So I would vote for disabling this by default and allow people to enable it if really needed.

Thanks a lot for this great tool 👍

fin swimmer

[Austin Bingham]

would be cool to see any progress in this topic

I'd love to have time to put into CR, but that's just not in the cards right now :(

But I have thought about annotations a bit. In some projects, I think you're right that modifying annotations is senseless. But in a growing number of situations, type annotations are critical for how the systems work. Off the top of my head, here a few situations where type annotations are important (and thus should be mutated):

• singledispatch where the type is inferred from the annotation
• Tools like dataclass and attrs which use annotation information at runtime
• Dependency injection systems where type annotation determine how dependencies are wired together

I've certainly worked on systems in both classes, so I'd like to find a way to make CR work in both cases. I suspect we could get very far with specific operators, e.g. one that only modifies type annotations for things that are important to dataclasses. It's an interesting area for experimentation.

Thanks a lot for this great tool 👍

I'm glad it's working for you!