A way to "register" the type to field mapping

[daveraja]

The new mechanism to determine the BaseField sub-class to use based on the field type declaration is currently hard-coded. It is flexible because it works with complex term fields, but it would be good to have a function that can be used to register the mapping to either register new fields or override existing ones.

[daveraja]

In infer_field_definition() I don't like the hard-coded mapping of bool, StrictBool, datetime.date, and datetime.time to a particular BaseField subclass.

In all these cases how the given python type is converted to ASP is just one of many options where there is no clear best way, so is something that would be very application specific.

For example, for dates I think currently it translates datetime.date to a string of the form "YYYY-MM-DD". While this reasonably, as it is fairly easy to read, but it is not the only option. It could be "YYYYMMDD" string or a tuple of integers (Y,M,D). Similarly, bool could be translated to a like "yes" or "Yes", but could also be a number 1 or an ASP constant "yes".

While it is true (with PR #132) that the user can override the default mapping, so something like:

import datetime
from clorm import Predicate, field

class MySpecialDateField(BaseField):
pytocl = lambda dt: dt.strftime("%Y%m%d")
cltopy = lambda s: datetime.datetime.strptime(s,"%Y%m%d").date()

class Booking(Predicate):
owner: str
date: datetime.date = field(MySpecialDateField)

However, it may still be convenient to want to rely on the type annotation, for example if you want to specify the same mapping multiple times. So I would like to change how the types are inferred to somehow be more user specifiable.

My current thought is to pass a dictionary to the class definition that adda the user specific mappings. So with the above example:

TYPE_MAPPING = {datetime.date: MySpecialDateField}

class Booking2(Predicate, type_map=TYPE_MAPPING):
    owner: str
    date: datetime.date

I also thought of trying to make it more implicit with some sort of "register" function call that modifies some internal clorm dictionary. But this would mean maintaining a global dictionary in clorm and I think maintaining internal global state in libraries is not a great approach.