validate() api considerations

[wbolster]

hey,

i'm wondering what made you decide to use a classmethod for Schema.validate() which then returns an instance of the schema.

i am wondering how this would work nicely when you're actually interested in creating custom (application specific) class instances, such as sqlalchemy orm class instances (‘database models’), since all attributes need to be copied afterwards.

also, to me ‘an instance of a schema’ is not the obvious answer for the question ‘what's the result of my validation’, yet typesystem seems to think that is fine.

just curious to hear your thoughts. thanks in advance!

[tomchristie]

Actually I think this might be a point worth considering.

You'll get a better idea of why I'd taken this path if you look at how orm is using typesystem https://github.com/encode/orm - in that case Model inherits from Schema.

It's useful having Schema classes be able to act like classes with fine-grained type validation, plus being able to use them in type annotations, but I can see arguments in favor of the other style too.

Options will be, either:

• Include a cast=... argument in order to allow casting to some other type.
• Switch schemas so that .validate is an instance method, and they return dicts by default, with controls for changing that behavior. (More in line with eg. Marshmallow)

[skewty]

Further to what @tomchristie said, what helped me understand his reasoning was a few remarks in the documentation about the treatment of a similar class instance or dict passed to __init__() (validation is not done). This allows for a faster code path option; you get to choose if you need validation or not.