Proposal: A richer structure for Python-side fast validators

[corranwebster]

Currently, fast validators are specified by a tuple, the first value of which is the validator type, and the subsequent items are additional values to be interpreted by the ctraits.c machinery for that validator type. The exact contents of the tuple are not standardized, and in the cases of some are rather obtuse (eg. coercible type checks, which has two sub-lists embedded in the tuple, with a None value as a terminator of the first list, rather than, say, a tuple with tuples in it).

Adding some richer structure would help here:

• using more nested structures (such as the making the expected structure of coercible (11, (...), (...))
• using named tuples, with different named tuples for each distinct validator type, and auto-assignment of the validator magic number.
• having standard positions for things like allow_none, which might permit consistent use of optional values.

In general, the code would be much more readable on the python side if we could write something like:

float_fast_validate = CoercingFastValidator(
    allow_none=False,
    base_types=(float, floating),
    coercible_types=(int, integer),
)

[corranwebster]

Note that this would require new validation constants for the new structures and to keep the old validators around for a while, or we would break pickle loading of old traits.