Shared field types

todays_paper_web/widgets/params.py holds custom Pydantic field types — not model base classes. View’s and DataSource’s Params hierarchies each have their own base model (ViewParams, DataSourceParams — see View/DataSource), deliberately not shared, since a widget and a data source don’t actually have anything in common beyond both wanting the same extra=ignore config; the two model hierarchies would otherwise be joined by a base class that isn’t doing anything except naming a coincidence. Color and Number below, by contrast, genuinely are shared — the same value type is meaningful as a field on either a ViewParams or a DataSourceParams subclass.

Color

A custom field type, not a model — a CSS color name or #hex code, parsed into a webcolors.IntegerRGB. Give a field the right default with Field(default_factory=...); an unrecognized value raises rather than silently falling back to a default.

class todays_paper_web.widgets.params.Color

Bases: object

A CSS color name or #hex code, parsed into a webcolors.IntegerRGB.

Same name-then-hex parsing as the pre-migration, now-removed View.decodeColor had, but with no separate “default on failure” behavior: an unrecognized color raises a validation error rather than silently falling back. Give the field itself the right default via Field(default_factory=...).

classmethod validate(value) → IntegerRGB

Number

Also a custom field type: an int or float, kept as whichever type was actually given — for a DataSource’s YAML params: field that might be a whole number in one config and a decimal in another (see weather.yr). A plain float field would silently turn 17 into 17.0; Union[int, float] is actively unsafe in this project’s Pydantic v1, since it tries int first and truncates a real float’s fractional part.

class todays_paper_web.widgets.params.Number

Bases: object

An int or float, kept as whichever type it already was.

For a DataSource’s YAML params: (unlike a widget’s XML attributes, already native Python types, not strings), a plain float field would silently coerce a whole-number int like 17 to 17.0 - harmless on its own, but a naive Union[int, float] is actively unsafe in Pydantic v1: it tries int first and truncates a real float’s fractional part (e.g. 55.64277 silently becomes 55) rather than falling through to float. This preserves whatever numeric type was given, without either problem.

classmethod validate(value)