enthought / enthought/traits

Proposal: A richer structure for Python-side fast validators

Open
#675 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
462
Forks
90
PR merge metrics
No merged PRs in 30d

Description

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),
)
```

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.