What exactly do you mean by "other annotations that would interfere with the runtime use of __annotations__"?

I can only assume that you are thinking of a situation where you are introspecting some function/method of unknown origin and you are trying to see if it has any annotations, in which case you are going to use them for a locally-defined use (e.g. generate an HTML form -- contrived example).

It sounds as if you are worried about being passed a function that in the past would not have any annotations (so you would just generate a default form based on the argument names) but which now has been annotated by a zealous programmer with type hints. And you are worried that those type hints will confuse (perhaps crash) the form-generation code.

I think initially we will just tell the user "don't use type annotations for form-handling functions", and also "don't run the type checker on that code".

The next stage would probably be to create a decorator (say, @form_handler) and request that all form handlers are thus decorated. The decorator wouldn't need to do anything -- we could just teach the type checker that @form_handler means that argument annotations mean something that's unrelated to type checking, and we would still have to tell the user "don't use type annotations for @form_handler functions", but at least they could run the type checker on files that contain form handlers (the handlers themselves just wouldn't be type-checked).

It should be easy enough to teach the type checker about such decorators; all you need is some kind of marker on the decorator function (perhaps itself a decorator :-).

Eventually users might encourage the form library's maintainers to move the form info elsewhere (e.g. in the decorator arguments) and then the marker on the decorator can be taken off.

But the initial stage seems a totally fine solution for 3.5, and it doesn't require anyone to do anything (it just requires some people to refrain from doing some new things -- which is much easier, because people are naturally aware that new things can cause new problems :-).