Type stub for a property setter that is supposed to normalise its input into but is unsafe

[Sam-Martin]

I'm trying to figure out how best to type the value parameter for the @dynamic_naming.setter of aws_xray.core.Recorder.

https://github.com/aws/aws-xray-sdk-python/blob/master/aws_xray_sdk/core/recorder.py#L544

Its intention looks to be to allow the user to pass in either:

1. A string to be converted into DefaultDynamicNaming
2. A DefaultDynamicNaming object or a subclass thereof.

BUT because it does a positive check for a str type and if it's anything else just sets it as the value of self._dynamic_naming, it could theoretically be any type.

[This stack overflow question/answer[(https://stackoverflow.com/questions/66595278/what-should-the-type-annotation-for-a-python-property-setters-argument-be) covers this scenario but from the perspective of the code owner. As I'm writing a stub I have no ability to change the internals of the method.

I want to type it as the compatible types (str | DefaultDynamicNaming) to ensure that people using the stub pass in a compatible type. BUT then mypy naturally complains at me for typing the return value of the getter as the type str values will get converted to (DefaultDynamicNaming), and strictly speaking it could be literally an value because the value is only converted if it's a str`.

Should I just type the setter value it as DefaultDynamicNaming despite it supporting strs? or is my only truthful option to type it as Any?

[Akuli]

This is a known mypy bug: python/mypy#3004

A decent workaround would be Any | DefaultDynamicNaming. It's not great for the setter, because it means that any object is accepted. But for the getter, it is not same as just Any like you might expect: if you do value_from_getter.foo for example, mypy will complain that DefaultDynamicNaming has no attribute foo, because it would be valid only if both union members had that attribute.