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
Currently this class is implemented as dataclass. Dataclasses are very useful as containers of data (hence the name) so that you can, for example, pass a class around rather than a dict, use dot access to its values, and easily print it out to see its values, etc. They are not the optimal choice when dealing with complicated state, implementing more than few methods to operate on that state, having required or optional arguments, etc.
It's very useful to handle these things at initialization, rather than after with a __post_init__ method, and is a lot more easy to understand as well. When lots of logic is ending up in a __post_init__() method it indicates that we should just use a standard class instead.
The current keyword argument semantics can be retained like so:
Here the ordering is not important when creating the class, config will be required to be provided as ExportData(config=...), and some_arg is optional. An empty initialization will cause ExportData() to raise a TypeError.
This gives a better sense of what the user is providing as input, how to validate or transform that input before it's set to a field. It also allows for state updates to be more transparent, immutable to users, and for methods to have better insight into what the state of any given variable is.
The text was updated successfully, but these errors were encountered:
Currently this class is implemented as
dataclass
. Dataclasses are very useful as containers of data (hence the name) so that you can, for example, pass a class around rather than a dict, use dot access to its values, and easily print it out to see its values, etc. They are not the optimal choice when dealing with complicated state, implementing more than few methods to operate on that state, having required or optional arguments, etc.It's very useful to handle these things at initialization, rather than after with a
__post_init__
method, and is a lot more easy to understand as well. When lots of logic is ending up in a__post_init__()
method it indicates that we should just use a standard class instead.The current keyword argument semantics can be retained like so:
Here the ordering is not important when creating the class,
config
will be required to be provided asExportData(config=...)
, andsome_arg
is optional. An empty initialization will causeExportData()
to raise aTypeError
.This gives a better sense of what the user is providing as input, how to validate or transform that input before it's set to a field. It also allows for state updates to be more transparent, immutable to users, and for methods to have better insight into what the state of any given variable is.
The text was updated successfully, but these errors were encountered: