Rebase on stricter types for fields

[roll]

• fixes Rebase on stricter types for fields? #11

---

Please make sure that all the checks pass. Please add here any additional information regarding this pull request. It's highly recommended that you link this PR to an issue (please create one if it doesn't exist for this PR)

[roll]

@khusmann
If you have some time, can you please take a look? In general, it seems to be just working. I didn't run into any problems in the implementation

[khusmann]

BEAUTIFUL! This is so nice to use:

In addition to the code completion, the types here really help with mapping / translating between formats (and converting all the fields properly) because I can guarantee I've handled all the possible cases via exhaustiveness checking (less unit tests needed to catch runtime errors!). Thank you so much!

---

Small suggestion -- I think you should make the BaseConstraints and ValueConstraints generic types, (which is supported by pydantic) rather than using Any in their properties.

This way, properties of constraints can return the correct types. For example, IntegerField.constraints would have type ValueConstraints[int]. Then, when I use constraints.enum, constraints.minimum or constraints.maximum, they will all return int types instead of Any .

Related: I've proposed a dialect.type field so we can do similar magic on the different possible types of dialect: frictionlessdata/datapackage#921

[roll]

@khusmann
Thaks for the review!

Small suggestion -- I think you should make the BaseConstraints and ValueConstraints generic types, (which is supported by pydantic) rather than using Any in their properties.

Good catch! Added generics now