refactor: remove dead _get_channels_mapping code#3467
Conversation
joelostblom
left a comment
There was a problem hiding this comment.
LGTM, but I'll leave it open in case someone else wants to confirm
|
Think there was a false positive in https://github.com/vega/altair/actions/runs/9905108163/job/27363929771?pr=3467 Can't repro locally >>> hatch test
cmd [1] | ruff check .
All checks passed!
cmd [2] | ruff format --diff --check .
84 files already formatted
cmd [3] | mypy altair tests
Success: no issues found in 367 source files
cmd [4] | pytest -p no:randomly -n logical --numprocesses=logical --doctest-modules tests altair
==================================== 1257 passed, 1 skipped, 1 xfailed, 2 xpassed in 52.68s ==================================== |
I see this is failing again in https://github.com/vega/altair/actions/runs/9905108163/job/27364311474?pr=3467 @mattijn should I fix this in a new PR or in this one? It isn't related to the changes I've made here at all |
|
Do we know where this error was introduced? I can't remember merging a PR with errors in CI. |
I've got a fix for it I'm about to push on a new PR #3475 It looks to be a change over at |
…rors` Fixes `mypy` error that appeared during a merge vega#3467 (comment)
…3475) * fix(typing): Confirm arg type before joining in `_deduplicate_enum_errors` Fixes `mypy` error that appeared during a merge #3467 (comment) * revert: undo last commit * revert: Ignore type error introduced by `typeshed` The issue is not related to any runtime changes python-jsonschema/jsonschema#1019 (comment)
I've been seeing this message for a while and thought I'd investigate.
This function appears in the first
v5commit toapialtair/altair/vegalite/v5/api.py
Lines 146 to 152 in 14bbb8d
It was not referenced back then (2021), and still is not referenced.
It looks like an early version of the
channelsmodule manipulation code replaced in #3444As this is a private function, I don't feel there's a strong case for keeping it around.
It also doesn't behave the same as the old
infer_encoding_types- so any hypothetical usage wouldn't produce the same spec: