Improve clr.accepts/returns

[BCSharp]

Laggard from #52.

[slozier]

Seems fine to me. Too bad the Checker classes are public - seems like unnecessary API surface (unless there's some use case I'm not thinking of).

[BCSharp]

Too bad the Checker classes are public - seems like unnecessary API surface (unless there's some use case I'm not thinking of).

I had the same reaction. I consider this part of API "legacy". It is rather limited in scope and was buggy so I expect it is not widely used. Going forward, rather than putting more effort into it, I'd rather see a clr.assertTypeAnnotations decorator.

[BCSharp]

@slozier, I've been thinking: maybe the moment before the final 3.4 release is a good opportunity to remove the Checker classes from public API after all? A migration from 2 to 3 is about breaking changes (though I think it is unlikely this would break anyone's existing code).

[slozier]

Fine by me. If someone really needs them they can file an issue.

[BCSharp]

It turns out those types have to be public in order to be callable from Python. I'm parking the issue.

[slozier]

It turns out those types have to be public in order to be callable from Python. I'm parking the issue.

Hmm, we could make them PythonHidden (and internal constructors maybe) so they don't show up on clr? Anyway, no big deal.