You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is despite dataclass definitions making their field information readily available for introspection on the class object (without requiring instantiation):
While for most dataclasses it is straightforward to instantiate a specific instance and derive the mock autospec from that, this may not be desirable (or even feasible) if the dataclass requires references to real external resources to create a real instance.
There are various potential workarounds available for this functional gap, but they're all relatively clumsy, and come with their own problems (like not being able to use spec_set=True if the missing fields are added manually, or not handling defined methods properly if setting an explicit list of fields instead of using autospec, or still not adding the fields only defined in __post_init__ if instantiating a class mock).
By contrast, if create_autospec were to be made explicitly aware of data classes, it could do a pass over dataclasses.fields(spec) and use the type information to fill in any missing fields that don't have class level default values set.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
Previously filed here, but closed on the basis of create_autospec covering the use case: #80761
This is only true if the dataclass can be readily instantiated, hence this feature request.
I already worked around it for my use case (leaving spec_set as False and adding in the missing attributes manually), so please feel free to take it on!
I think the basic cases where the field types are just a simple type will be straightforward (use create_autospec(..., instance=True) recursively), and the some_type|None/Optional[type] case can ignore the None branch and do the same. ClassVar and InitVar will already be filtered out by the fields(...) call.
Checking the result of dir(str|int) it might be OK to simply not do anything special for non-trival unions and other more complex type definitions like generic containers. The mock may end up with some additional methods it wouldn't otherwise have, but that's probably an acceptable limitation. For example:
Feature or enhancement
Proposal:
Passing
instance=True
tocreate_autospec
misses fields without default values, even when the given spec is adataclass
object:This is despite dataclass definitions making their field information readily available for introspection on the class object (without requiring instantiation):
A similar problem occurs if the dataclass uses
__post_init__
to set attributes that are not otherwise set:While for most dataclasses it is straightforward to instantiate a specific instance and derive the mock autospec from that, this may not be desirable (or even feasible) if the dataclass requires references to real external resources to create a real instance.
There are various potential workarounds available for this functional gap, but they're all relatively clumsy, and come with their own problems (like not being able to use
spec_set=True
if the missing fields are added manually, or not handling defined methods properly if setting an explicit list of fields instead of usingautospec
, or still not adding the fields only defined in__post_init__
if instantiating a class mock).By contrast, if
create_autospec
were to be made explicitly aware of data classes, it could do a pass overdataclasses.fields(spec)
and use the type information to fill in any missing fields that don't have class level default values set.Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
Previously filed here, but closed on the basis of
create_autospec
covering the use case: #80761This is only true if the dataclass can be readily instantiated, hence this feature request.
There is also some previous discussion (and assorted attempted workarounds with various flaws) on this Stack Overflow question: https://stackoverflow.com/questions/51640505/how-to-use-spec-when-mocking-data-classes-in-python
The text was updated successfully, but these errors were encountered: