DEV Community: Thisal Dilmith

How I Built a Live-Updating Line Chart Widget for Tkinter Without Any External Dependencies

Thisal Dilmith — Fri, 26 Jun 2026 18:11:30 +0000

The Problem

Tkinter ships with enough widgets to build a functional desktop GUI in an afternoon.
What it doesn't ship with is any built-in way to display data that changes over time.
If you're building a CPU monitor, a sensor dashboard, or any tool that needs to
visualize a live stream of values, you have two realistic options: embed matplotlib
in a FigureCanvasTkAgg, or roll your own canvas drawing logic. The first option
works but pulls in a dependency that's larger than most projects need. The second
option means rebuilding the same axis, scaling, and rendering logic every time.

Why Existing Solutions Didn't Cut It

The matplotlib-in-Tkinter approach is the most commonly recommended solution, and
it's fine for static charts. For live data though, it has friction:

You manage figure/canvas lifecycle manually.
Animation via FuncAnimation fights with Tkinter's event loop unless you're careful with blit=True and backend selection.
The import footprint (numpy, matplotlib) is heavy for an app whose chart is a minor feature.

The other option — drawing on a tk.Canvas directly — is fine at small scale but
requires you to reimplement axis labels, scaling, grid lines, and multi-line
coordination every single time.

What I wanted: a LineChart class I could drop into any Tkinter app the same way
I'd drop in a ttk.Treeview. Create it, pack it, feed it data. Done.

How It Works

tkchart exposes two classes: LineChart (the widget) and Line (a data series
attached to a chart).

import tkchart

chart = tkchart.LineChart(
    master=root,
    x_axis_values=("t-9", "t-8", "t-7", "t-6", "t-5",
                   "t-4", "t-3", "t-2", "t-1", "t"),
    y_axis_values=(0, 1000),
    y_axis_section_count=5,
    x_axis_section_count=10,
)
chart.pack(pady=10)

line = tkchart.Line(
    master=chart,
    color="#5dffb6",
    size=2,
    style="dashed",
    style_type=(10, 5),
    fill="enabled",
)

LineChart owns the canvas, axes, labels, and grid. Line is a lightweight
descriptor — it holds style properties and a data buffer, but the chart controls
all rendering.

Feeding data happens via show_data():

def stream():
    while True:
        chart.show_data(line=line, data=[random.randint(0, 1000)])
        time.sleep(0.5)

threading.Thread(target=stream, daemon=True).start()

This is designed to be called from a background thread. Internally, canvas
operations are dispatched to the main thread via Tkinter's after() mechanism —
the caller doesn't have to think about it.

Key architectural decisions:

Decoupled Line from LineChart: Each Line maintains its own data
buffer independently. get_line_data(), get_current_visible_data(), and
related methods let you query what's on screen at any point — useful for
triggering alerts or logging snapshots.
Scrolling X-axis: As data arrives, the X-axis label set scrolls. The
x_axis_values tuple defines the visible label template, not a fixed dataset.
This means the chart is conceptually infinite on the time axis.
Runtime reconfiguration: v2.2.0 added configure_*() methods for almost
every visual property. You can change axis colors, pointer behavior, or
line fill at runtime without destroying and recreating the widget.

   chart.configure_bg_color("#1a1a2e")
   line.configure_color("#ff6b9d")
   line.configure_fill("enabled")

Pointer with callback: An optional hover pointer shows interpolated values at cursor position and fires a user-supplied callback function — so you can wire it to a label or trigger an action based on which data point is hovered.

One Thing That Surprised Me

The show_data() call accepts a list, not a single value. I intended this to
support batch inserts — you can push multiple data points in one call, and the
chart will render them all in sequence.

The tricky part: when multiple Line objects share the same LineChart, their
data lengths need to stay synchronized for the X-axis to remain coherent. The
chart uses the maximum data length across all lines as its internal clock. If one
line accumulates data faster than another, the slower line's visible portion gets
padded implicitly.

This means callers have to be deliberate about calling show_data() at consistent
rates across all lines if they want correct synchronization. It works well when all
lines are driven from the same loop (the common case), but it's a real footgun if
you have two independent threads pushing to two separate lines at different intervals.

I haven't found a clean solution that doesn't add per-line timestamps and complicate
the rendering model significantly. For now, the docs recommend keeping all
show_data() calls inside a single loop.

What's Next

Bar chart support: The LineChart architecture is canvas-based enough that adding a BarChart class is feasible. The axis and label system could be shared.
Export: A method to snapshot the current canvas state to a PNG. The tk.Canvas.postscript() method gets close but requires an extra conversion step.
Typed stubs: The codebase predates type hints. Adding .pyi stub files would make autocomplete and mypy integration much better.

Call to Action

The design decision I'm least certain about: the Line-as-descriptor pattern
where Line holds style but LineChart owns all rendering. It keeps the rendering
logic centralized, but it means Line objects are inert outside the context of their
parent chart.

An alternative would be to make Line a proper canvas actor that draws itself —
closer to how matplotlib's Artist hierarchy works. That would allow lines to be
moved between charts, but it would also scatter the rendering logic.

If you've designed a similar multi-series chart component — in any language or
framework — I'd genuinely like to hear which pattern held up better over time:
centralized renderer or autonomous actors.

GitHub: https://github.com/thisal-d/tkchart

PyPI: https://pypi.org/project/tkchart/

PyPI: pip install tkchart

[Boost]

Thisal Dilmith — Fri, 26 Jun 2026 14:58:40 +0000

Thisal Dilmith

Jun 25

Why GridSearchCV Wastes Most of Its Time — And What I Did About It

#python #machinelearning #datascience #opensource

4 min read

Why GridSearchCV Wastes Most of Its Time — And What I Did About It

Thisal Dilmith — Thu, 25 Jun 2026 20:16:05 +0000

If you've ever tuned hyperparameters on a large grid, you know the pain. You kick off a GridSearchCV, go make coffee, come back, and it's still running. Maybe you go to lunch. Maybe it's still running.

I got frustrated enough to build something different. It's called EliminationSearchCV

The Problem with GridSearchCV

GridSearchCV is brute force by design. For a grid with k parameters and n values each, it evaluates nᵏ × cv_folds configurations — every single one, regardless of how poorly a value performs early on.

Here's what that actually means in practice:

Problem	Impact
Dead-end values are never discarded	A bad `learning_rate=0.5` is re-evaluated in every downstream combination
No learning from early results	The search treats round 1 and round 1000 as equally uninformed
Exponential cost scaling	Adding one new 4-value parameter can quadruple total training time

The last point is the killer. Your grid doesn't have to be huge for this to hurt — it just has to grow.

The Idea: Eliminate Instead of Enumerate

What if instead of evaluating everything upfront, we tested parameter values in rounds — and dropped the bad ones before they compound?

That's EliminationSearchCV.

It works like this:

Round 1: Test each parameter value in isolation. Score them per-parameter and eliminate the worst performers.
Round 2: Test surviving pairs. Rank all combinations globally, keep the top fraction.
Round 3+: Repeat with triples, then full combinations, until one winner remains.

Bad values get cut early. They never get the chance to multiply into thousands of useless combinations.

A Concrete Example

Let's tune a LogisticRegression with 4 parameters:

param_grid = {
    'C':        [0.001, 0.01, 0.1, 1, 10, 100],   # 6 values
    'penalty':  ['l1', 'l2'],                       # 2 values
    'solver':   ['liblinear', 'saga'],              # 2 values
    'max_iter': [1000, 2000],                       # 2 values
}
# GridSearchCV: 6 × 2 × 2 × 2 = 48 combos × 5 folds = 240 fits

With EliminationSearchCV and elimination_rate=0.8 (keep best 20%):

Round	Combos tested	Grid after elimination
1 — single params	12	`C:[1], penalty:['l1'], solver:['liblinear'], max_iter:[1000]`
2 — pairs	6	unchanged (already 1 value each)
3 — triples	4	unchanged
4 — full	1	final result
Total	23 fits	vs 240 for GridSearchCV

Same best params. A fraction of the work.

Drop-in Replacement

The API is intentionally identical to GridSearchCV:

from EliminationSearchCV import EliminationSearchCV

# Before
search = GridSearchCV(model, param_grid, cv=5)

# After — just swap the class name
search = EliminationSearchCV(
    estimator=model,
    param_grid=param_grid,
    scoring='accuracy',
    cv=5,
    elimination_rate=0.8,  # eliminate worst 80% each round
)

search.fit(X_train, y_train)

# Same interface as GridSearchCV
print(search.best_params_)
# → {'C': 1, 'penalty': 'l1', 'solver': 'liblinear', 'max_iter': 1000}

print(search.best_score_)
# → 0.9248

# Already refitted on full training set — ready to predict
search.best_estimator_.predict(X_test)

One Thing I'm Proud Of: Invalid Combo Handling

Sklearn can raise errors for incompatible combinations — like penalty='l1' with solver='lbfgs'. GridSearchCV crashes on these. You have to manually filter them out.

EliminationSearchCV catches any exception during fit(), scores that combination 0.0, and lets the elimination logic handle it naturally. Invalid combos just die in Round 1. No special handling needed from you.

Benchmark Results

Tested across 5 models and 3 datasets (cv=2, elimination_rate=0.8, 10,000 samples):

Model	Grid	Speedup	Accuracy diff
DecisionTree	Full	152x	-0.0008
RandomForest	Full	36x	-0.0002
GradientBoosting	Full	35x	-0.0194
KNeighbors	Full	11x	-0.0004
LogisticRegression	Full	4x	-0.0004

Full grids are where this shines. The accuracy trade-off is minimal — under 0.02 across all models, often zero.

Honest caveat: Light grids (small search spaces) are actually slower with this approach. The elimination overhead doesn't pay off when there are only a few combinations to begin with. If your grid is small, stick with GridSearchCV.

Architecture: How It's Built

The library is two files:

src/EliminationSearchCV/
├── EliminationSearchCV.py   ← Core class: fit(), elimination logic, scoring
└── Utils.py                 ← Stateless utilities: fold creation, combination generation, metrics

The flow inside fit():

EliminationSearchCV.fit(X, y)
    │
    ├─▶ Utils.create_cv_data_sets()         — StratifiedKFold/KFold splits
    │
    └─▶ [For each round i = 1 … n_params]
             │
             ├─▶ generate_param_combinations_with_limit(grid, limit=i)
             │
             ├─▶ _score_candidates(candidates)
             │         — per-fold metric evaluation
             │
             └─▶ _eliminate_low_scoring_values(candidates, scores)
                       ├─▶ _eliminate_single_param_values()   — Round 1
                       └─▶ _eliminate_multi_param_values()    — Rounds 2+

A key design decision: in Round 1, each parameter's values are scored and compared in isolation — so C values compete only against other C values, not against penalty values. This prevents interference between parameters that are on completely different scales.

In later rounds, all combinations are ranked globally and the top (1 - elimination_rate) fraction survives.

What's Working and What's Not Yet

Currently supported:

fit(), best_params_, best_score_, best_estimator_
Round 1: per-parameter isolation and elimination
Rounds 2+: global combination ranking
StratifiedKFold / KFold cross-validation
Invalid combination handling
Scoring: accuracy, precision, recall, f1, roc_auc

On the roadmap:

cv_results_ (per-fold score breakdown)
n_jobs parallel evaluation via joblib
verbose logging
Full pytest test suite
Scikit-learn BaseEstimator compatibility

Try It

pip install elimination-search-cv

Requirements: Python ≥ 3.8. scikit-learn and numpy install automatically.

GitHub: https://github.com/thisal-d/elimination-search-cv

Honest Disclaimer

This is an experimental approach. The quality of results depends heavily on the dataset and model. I'm actively benchmarking it and the results so far are promising — but I wouldn't call it production-ready yet.

What I'd genuinely love is feedback on edge cases where it fails. If you try it on a grid where it gives clearly wrong results or behaves unexpectedly, please open an issue. That's more useful to me right now than praise.

If you found this interesting, a ⭐ on the repo helps a lot — it keeps the motivation alive to keep building.

Tags: python machinelearning datascience opensource