Overriding `Schema` instantiation.

[lovelydinosaur]

Eg:

1. Use a schema class, but just instantiate a plain dict.
2. Use a schema class, but instantiate a different type. (Eg. seperate schema from model class)

[skewty]

Is one of the purposes of this issue / feature request to provide type hinting in VSCode and PyCharm?

from datetime import date
import typesystem

class Artist(typesystem.Schema):
    name = typesystem.String(max_length=100)  # type: str

class Album(typesystem.Schema):
    title = typesystem.String(max_length=100)  # type: str
    release_date = typesystem.Date()  # type: date
    artist = typesystem.Reference(Artist)  # type: Artist

album = Album.validate({
    "title": "Double Negative",
    "release_date": "2018-09-14",
    "artist": {"name": "Low"}
})

album.artist.name  # the expected resultant type of name is str but the inspector shows Field unless I add the # type as above.

Is your issue about making Field class more of a mix-in (or use composition instead of inheritance)?

I am interested because this lack of correct type being provided by the inspector is a deal breaker for my team. The #type type override is perhaps an acceptable band-aid though as ugly as it is.

NOTE: pydantic, although not nearly as elegant and simple to use as typesystem in my opinion, provides the expected field type to the inspector by using the plain type. Perhaps that project should be mentioned in the Alternatives section of README.md.

Thanks!

[lovelydinosaur]

Is one of the purposes of this issue / feature request to provide type hinting in VSCode and PyCharm?

Not specficially, but I guess that's a bit related. I'm just not convinced by my earlier design decision to have the schemas be instances themselves. I think it'd likely be neater if they were just that classes that provided the validate/serialize behavior. (And have the actually instances themselves be whatever actual type you want to use for the models)

Btw. Very welcome to add pydantic to the relevant README section if you'd like, yup.