Currently if you use typing.Any in an annotation, this will result in the message Annotation for field '<context>' is not a type. While this is technically correct (Any is not a subclass of type), it isn't very helpful to the end user.
One solution would be to add a dedicated error message saying that Any is unsupported.
Alternatively, we could support Any by accepting any data type that the TOML parser can produce. While this doesn't provide type safety, there might be situations where providing a full type hierarchy is not feasible or not worth the effort, for example when configuring plugins or optional modules. Without Any support, the only solution would be to cut out specific fields from the parsed TOML data prior to calling the bind() method and then re-inserting them after binding, which is messier than using an Any annotation.
Currently if you use
typing.Anyin an annotation, this will result in the messageAnnotation for field '<context>' is not a type. While this is technically correct (Anyis not a subclass oftype), it isn't very helpful to the end user.One solution would be to add a dedicated error message saying that
Anyis unsupported.Alternatively, we could support
Anyby accepting any data type that the TOML parser can produce. While this doesn't provide type safety, there might be situations where providing a full type hierarchy is not feasible or not worth the effort, for example when configuring plugins or optional modules. WithoutAnysupport, the only solution would be to cut out specific fields from the parsed TOML data prior to calling thebind()method and then re-inserting them after binding, which is messier than using anAnyannotation.