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
The descriptors approach wasn't considered at the time of writing this library mostly because I wasn't an active user of the descriptors in general.
The idea seems kinda nice indeed. However there's a number of things to be considered if we are to implement this approach.
The use of descriptors will effectively make all fields optional for the class constructor. What I mean is something like this wouldn't be detected as a problem by the type checker anymore:
user=User() # creating a user with no arguments
How do we implement the descriptors for fields with compound values (objects and arrays)?
Naming logic must be addressed too, since field name collision is possible (consider having two fields named foo and _foo in a model)
Could you also provide an example of a descriptor for some type that would actually require a conversion from/to JSON, as opposed to int?
From readme I see
Which makes me curious on why to define an argument named
_conversion
, is this a design decision for some reason?What about implementing that using the
descriptor
protocol?And having all
*Field
to be implementation of descriptors such as:The text was updated successfully, but these errors were encountered: