`dataviz_mojo`

This package’s public surface: everything a caller is meant to import, re-exported here so from dataviz_mojo import bar, Plot, Theme works without anyone needing to know which file inside the package a given name actually lives in.

That indirection matters most for the one-call convenience functions (bar, scatter, pie, …): each one lives in its mark’s file, next to that mark’s rendering code (see plot.mojo’s module docstring, its “one-call convenience functions” section, for the rule and why), so their real module paths – dataviz_mojo.bar.bar, dataviz_mojo.arc.pie – are an internal layout detail that would be noisy and surprising to import directly. Import them from the package, not from the file.

Every name below is listed explicitly – a deliberate, considered addition to this package’s public surface – with one exception: colors.mojo’s ~148 CSS-named Color constants (from dataviz_mojo. colors import *, the one wildcard import in this file). Those aren’t individually-designed features to enumerate one by one, just a single fixed, already-standard vocabulary (see that file’s docstring) – listing RED, BLUE, CORNFLOWERBLUE, … by hand here would be pure noise a spec already settled, not documentation of a real choice made in this package.

Modules

arc
arc_diagram
bar
beeswarm
box
bullet
bump
calendar_heatmap
candlestick
chord
color_scale: ColorScale – maps a continuous data domain onto a color gradient, for data-driven color encoding (Plot.encode(color=...)). Shares its stop-interpolation logic with canvas_mojo.gradient’s LinearGradient/ RadialGradient via that module’s _color_at_t/_GradientStop – identical math (bracket the two nearest stops, linearly interpolate), only the projection differs: those two project a pixel position (an axis, or a radial distance) onto [0, 1]; this one projects a data value onto [0, 1] via a plain domain, the same domain-to-[0,1] idea LinearScale uses for position, generalized to color instead of a pixel coordinate.
colors: Named colors – the full CSS Color Module Level 3 / X11 “extended color keywords” list (https://www.w3.org/TR/css-color-3/#svg-color), plus REBECCAPURPLE (added in Level 4, but universally bundled alongside the rest of this list by every implementation of “the CSS named colors” in practice, not just formally part of Level 3), as Color constants: Theme(mark_color=CORNFLOWERBLUE) instead of hand-typing Theme(mark_color=Color(100, 149, 237)) (see #10 – “make ‘green’ and similar colors just available to specify”). Each name is the CSS keyword itself, uppercased, with no separators added (CORNFLOWERBLUE, not CORNFLOWER_BLUE) – that keeps every name a direct, greppable match for the CSS spec/any color picker a caller already knows the keyword from, rather than a second, dataviz_mojo- specific spelling to remember. Both spellings CSS itself standardizes (GRAY/GREY, DARKGRAY/DARKGREY, DIMGRAY/DIMGREY, LIGHTGRAY/LIGHTGREY, LIGHTSLATEGRAY/LIGHTSLATEGREY, SLATEGRAY/SLATEGREY) are both included, each the identical Color value under both names – picking one and dropping the other would just be a different, equally arbitrary standard.
corrplot
edges: The shared edge-list core behind the network family (Mark.CHORD/ARC_DIAGRAM/GRAPH/SANKEY): every one of those marks reads the same three columns from Plot.encode_chord() – a from name, a to name and a magnitude per row – and every one needs the same two answers about them before any mark-specific layout (a ring sector, an arc, a node circle, a column) can be computed: are the columns well-formed, and where does each endpoint sit in the node domain.
effect_scatter
funnel
gantt
gauge
graph
grouped_bar
heatmap
hierarchy: The shared tree-indexing core behind the hierarchy family (Mark.SUNBURST/TREE/TREEMAP): every one of those marks needs the exact same three answers about Plot.encode_hierarchy()’s flat ids/parent_ids/values rows – who is whose child, how deep is each node, and what’s each node’s subtree total – before any mark-specific layout (a ring sector, a node position, a rectangle) can be computed. Shared by all three callers.
histogram
lollipop
marimekko
mark: The geometric primitive a data row becomes – the grammar-of- graphics mark concept. Follows the same small-struct-with-comptime- constants-and-__eq__ pattern canvas_mojo.FillRule/canvas_mojo.TextAlign use, not a distinct enum mechanism.
nightingale
ordinal_scale: OrdinalScale – maps a fixed-order list of discrete categories onto evenly spaced pixel bands, the standard “band scale” every bar-chart- style categorical axis needs (matches d3’s scaleBand in spirit: one padding fraction, applied as an equal gap on both sides of every band, not separate inner/outer padding knobs).
output_format: The file format save() (this module’s sibling plot.mojo) writes when a caller hands it a Plot and a path, rather than picking a canvas_mojo backend by hand. Follows the same small-struct-with- comptime-constants-and-__eq__ pattern Mark (mark.mojo) and canvas_mojo’s FillRule/TextAlign use, not a distinct enum mechanism.
parallel
plot: Plot – the fluent builder for this package’s first vertical slice: basic X-Y plots (scatter via Mark.POINT, line via Mark.LINE). Data is plain columnar List[Float64]/List[String], passed to encode()/ encode_categorical() directly – a 1-D array is all any chart type here needs; a named-column Table abstraction was built and then removed (see the wiki’s Changelog) once it turned out to add a second way to do the same thing without a concrete need for named-column lookup driving it.
polar
polar_bar
population_pyramid
punchcard
radar
radialbar
ridgeline
sankey
scale: LinearScale – maps a continuous data domain onto a pixel range, and picks “nice” tick positions within that domain for axis labeling. This is the piece canvas_mojo.geometry.Transform2D’s docstring already named as deferred here: scale()/translate() below compute exactly the slope/intercept Transform2D’s affine map takes, so Plot builds one Transform2D from an x-scale and a y-scale (with the y-scale’s range reversed – pixel y increases downward, data y conventionally increases upward, the same “negative scale_y” trick Transform2D’s docstring documents) rather than reimplementing the linear map here.
single_axis
span_chart
stacked_bar
streamgraph
sunburst
theme: Visual defaults for a Plot – colors, sizes, margins – kept as one small struct with sensible defaults rather than a dozen optional parameters scattered across Plot’s builder methods. This is deliberately the one place in this early vertical slice that borrows ECharts’ “config object” ergonomics (a bundle of display knobs) rather than the grammar-of-graphics vocabulary the rest of dataviz follows – appropriate here specifically because a theme isn’t part of the data grammar (it doesn’t change what a mark or scale means), just how it looks.
tree
treemap
violin
waterfall