Open mnieber opened 1 year ago
Although I can see that the repetition is not that satisfying, I think this feature would add a lot of complexity and possibly fragility to dataclassy itself for a marginal reduction in verbosity (factories are not incredibly common, I think). Right now Factory
(the implementing class) and factory
have no knowledge whatsoever of data classes or the __annotations__
dict and I like that elegance.
Also note that the type hint and argument to factory
are not necessarily redundant. For example, imagine the case where PostProcessSourceCodeFn
has various subclasses. All are valid but one must be used as the default. In this case you could easily have post_process_source_code_fn: PostProcessSourceCodeFn = factory(PostProcessSourceCodeFnSubclass)
. You can see that sometimes both type hint and argument would be needed, which means you need to have two ways factory
can be used, which adds complexity to the user.
factory
could be enabled without complicating the factory function itself. I suppose you do some introspection of the class that was annotated with dataclass
? During this introspection, we could replace field: SomeType = factory
with field: SomeType = factory(SomeType)
. In other words, the complexity would be added to the introspection, not to factory
.That said, it's only a minor improvement, I'm already very happy with the existing solution.
First of all, great work!
I wondered if the verbosity of the code could be further reduced by allowing the factory function to be used without arguments. In that case, the argument to
factory
should be derived from the type annotation. E.g.Of course, this is only a minor improvement, but still potentially a useful one.
By the way, it seems that the following alternative has a drawback (for me), since vscode fails to detect the type of
post_process_source_code_fn
and therefore symbol lookup doesn't work.