I think this should actually be contravariant, not covariant - this doesn't affect usage in the method definitions, but for the type aliases, since they are callables, we want them to be contravariant, I think. Please correct me if I'm wrong - my first encounter with covariance and friends.

From what I understood, making this covariant means that wherever a MaybeExtensionValidator[A] is accepted, a MaybeExtensionValidator[B] would also be accepted, where B is derived from A. But I don't think that's a good idea. Contravariance would mean that MaybeExtensionValidator[A] would be accepted wherever MaybeExtensionValidator[B] is accepted, and that seems potentially useful in some specific cases - i.e. for example the user might want to create some extension validation callback that accepts any type (type hint would be for x509.ExtensionType) and re-routes the validation to some other structure in their code.

The mypy docs describe why contravariance makes sense for callables better than I do.

right. so, do you feel we need to put explicit contravariant=True or leave it default?

Explicitly mark contravariant I think, because with the old type syntax it's neither by default, and the new one defaulted this to contravariant. I think it's best to keep it that way, since the use case of passing in an extension validator that accepts any extension can be valid under some very specific circumstances (and I'm pretty sure I did that in tests).

@alex can you please double check that my understanding of co/contravariance is correct when you have a chance? 😄

I think leaving it blank makes it invariant, and that's fine?

Imo that's a bit needlessly prohibitive since then you wouldn't be able to pass in an extension validator that accepts any extension. I'm pretty sure that would make type checking fail for the tests. The real world use cases I can come up with are extremely contrived, but I think it's worth keeping it contravariant just for the tests since it doesn't hurt anything imo.

Not sure about the tests tbh, basically either nothing or explicitly contravariant should be fine. Not a deal breaker imo.

My understanding is that inavariant is the same behavior as the prior type annotation:

>>> def f[T: datetime.datetime](t: T): pass
... 
>>> f.__annotations__
{'t': T}
>>> t = f.__annotations__["t"]
>>> t.__covariant__
False
>>> t.__contravariant__
False

this is different since it's a function accepting a type, there any sort of variance is not defined since the function itself is not generic, it just accepts a generic argument. If you defined a type alias for a callable with the new syntax I'm quite sure it would be contravariant. (Or alternatively a function which accepts a generic callable.)

The idea is that when u accept a callable you want to accept a callable for a specific type or a callable for a more generic type - all you care about is that you can call it with your type.

(at least mypy docs explicitly say that generic callables are contravariant by default with the new syntax)