Prioritize Optionals based on one level of depth traversal. Close #44, #45.

[erikrose]

This enables the common pattern in which there's a 'foo' key with a default and we also take arbitrary other, optional str keys.

We turn priority() into a delegating "generic function", like len().

This lays the groundwork to go deeper--with any "flavor", not just Optionals. First, we'd want to refactor Schema.validate() so it constructs actual Schema subclasses all the time rather than handling many cases inline. For sets, for example, it would construct an Iterable, and Iterable.priority() would know how to tunnel one level inside itself to return a compound priority. Then we could prioritize Optional((1, 0)) over Optional((int,)). The behavior of And() and Or() (and iterables) are up for grabs: perhaps go with the priority of the most specific item inside?

[erikrose]

Here's one more for you, Vladimir. What do you think? I'm rather enthused to do the mentioned refactoring as well, if you like.

[keleshev]

Love the idea of including priority into implicit Validatable interface. Here's what I was thinking recently: validate is a huge type-conditional on many types and priority is a huge type-conditional—that sounds like a great place for dynamic dispatch. How about: Schema constructor walks our schema DSL structure and constructs a proper schema with converting:

• str -> Type(str)
• [a] -> Iterable([a])
• a -> Literal(a)

With each of the Type, Iterable, Literal having appropriate validate method and priority property. We'll be able to get rid of a priority function, and split the huge Schema.validate into many smaller methods like Type.validate. And custom user classes will be able to specify their own priority. At that point we will be able to easily compose priorities, we could say that Optional has priority of its child, which in turn might compute or pick priority from it's children.

What do you think?

[keleshev]

Not to forget, but a minor concern: if priority becomes part of public interface, then we should see if there's anything better than int for it.

[keleshev]

Oh, my! I should have read your #55 first :-)