Provide a sensible default cast based on the default type

[hernantz]

• If the user provides a cast function, we use that one, no questions asked.
• if the user sets a default that is an int, str, boolean, float, etc, and doesn't set a cast function, we can set a default one: int(), str(), boolean(), float(), respectively.
• If the user doesn't set a default value we use the identity cast.
• If the user sets a non callable value as cast, we raise an exception.

Also allowed default to be a callable too.

Will submit the tests and docs soon.

[osantana]

hmm... I'm not sure that I like this behavior. I think that cast is a helper feature that needs to be used carefully and for this purpose, I think that "Explicit is better than implicit". So, I think that the developer MUST think and MUST specify explicitly the cast that needs to be used to convert the value. Even the default value.

[hernantz]

I think that the zen of python its a description of the ideas that formed the language,
in the case of "explicit vs implicit" we are talking about the self argument for methods. But this statement is broad and full of grey areas, even within python.

For example explicit typing (java) might not be better that implicit typing (python),
default arguments in function signatures do exist so that we don't have to force developers to always set explicit parameters on every function call.

As a closer example, prettyconf sets default loaders if the user doesn't explicitly provide them. The idea behind this PR follows that same principle, but for casts.

[osantana]

I think that the zen of python its a description of the ideas that formed the language,
in the case of "explicit vs implicit" we are talking about the self argument for methods. But this statement is broad and full of grey areas, even within python.

When Zen of Python says "explicit is better than explicit" they are talking more than only about typing or self. They are talking about things like not "casting silently" one object (eg. like in JS that tries to convert '1' to 1 in a comparison like '1' == 1 // returns true. I prefer, as a developer, to take care of the casting of my objects (and get errors when they fail).

Most of the time the Python language, by design, requires that all 'casting' (conversions) of objects needs to be made explicitly and raises errors* when it can't operate on different types. I want to keep prettyconf respecting it.

• There exceptions on this behaviour (raise errors) when we compare containers objects. But I see this as a bad design of the language.