Duh, it’s called strong language for a reason.

I haven’t timed it, but easily below a second.
Could that be optimised? Most certainly.

Due to the ranges being in a set, rather than a list, the input order doesn’t matter anyway. And the set really does a lot of heavy lifting for making the code so concise. You’ll need a bunch of boilerplate for list maintenance, especially of you continuously keep it sorted.
The set also removed 8 duplicates I had in the input.

Managed to keep it compact, but boy, do I hate cephalopod math >_<

Python

from csv import reader
from functools import reduce
from itertools import pairwise
from operator import mul
from pathlib import Path
from typing import Any, List, Sequence


def _calc(values: List[str]) -> int:
    match values[-1]:
        case "+":
            return sum(map(int, values[:-1]))
        case "*":
            return reduce(mul, map(int, values[:-1]))
        case _:
            return 0


def _transpose(values: Sequence[Sequence[Any]]) -> List[List[Any]]:
    return [[values[row][col] for row in range(len(values))] for col in range(len(values[0]))]


def part_one(input: str) -> int:
    def _parse_input(input: str) -> List[List[str]]:
        return _transpose(list(map(lambda r: list(filter(None, r)), reader(input.splitlines(), delimiter=" "))))

    return sum(map(_calc, _parse_input(input)))


def part_two(input: str) -> int:
    def _parse_input(input: str) -> List[List[str]]:
        data = list(input.splitlines())
        columns = [t[0] for t in filter(lambda t: t[1] != " ", enumerate(data[-1]))] + [len(data[0])]
        numbers = [[line[a:b] for line in data[:-1]] for a, b in pairwise(columns)]
        numbers = [list(filter(None, ["".join(num).strip() for num in column])) for column in map(_transpose, numbers)]
        return list(map(lambda t: t[0] + [t[1]], zip(numbers, list(filter(None, data[-1].split(" "))))))

    return sum(map(_calc, _parse_input(input)))


if __name__ == "__main__":
    input = Path("_2025/_6/input").read_text("utf-8")
    print(part_one(input))
    print(part_two(input))

Again part 2 took me way longer than I would’ve liked and also than feels appropriate for the simplicity of the solution I finally came up with.
Turned out quite fast, thanks to the ranges.

Python

from pathlib import Path
from typing import List
from itertools import combinations

def parse_input(input: str) -> tuple[set[range], list[int]]:
    parts = input.split("\n\n")
    fresh = set((lambda r: range(int(r[0]), int(r[1]) + 1))(line.split("-")) for line in parts[0].splitlines())
    return (fresh, list(map(int, parts[1].splitlines())))


def merge_ranges(a: range, b: range) -> List[range]:
    if a.stop <= b.start or b.stop <= a.start:
        return [a, b]
    return [range(min(a.start, b.start), max(a.stop, b.stop))]


def part_one(input: str) -> int:
    fresh, available = parse_input(input)
    return len(list(filter(None, [any(i in r for r in fresh) for i in available])))


def part_two(input: str) -> int:
    fresh, _ = parse_input(input)
    while True:
        for a, b in combinations(fresh, 2):
            if len(m := merge_ranges(a, b)) == 1:
                fresh.remove(a)
                fresh.remove(b)
                fresh.add(m[0])
                break
        else:
            break
    return sum(map(len, fresh))


if __name__ == "__main__":
    input = Path("_2025/_5/input").read_text("utf-8")
    print(part_one(input))
    print(part_two(input))

I learned to braid my hair.

Welchen Teil von “Nikotin in jeglicher Form” hast du nicht verstanden?

Esst lieber die reichen Kinder, die sind nicht so zäh.

What’s that, coming over the hill?

Yes, but he did it while being black, you see. That evens it out. /s

Just not for it.

But you’re not the first one to make that up, at least.

But isn’t it automatically once youth flip it?

You could’ve made it -halF

Couldn’t find anything useful on what that might be.

Incorrect comma.

Or stop overfeeding your cats.

Nushell is awesome. Passing structured data instead of strings makes mangling it so much easier. No more repeated string parsing.
My only gripe is that the devs sometimes make the syntax different from virtually every other shell only for the sake of being different.
It’s still my daily driver.

I hope they’re anti-anxiety pills.

I think that term gets confused frequently in this context. Stability as the Debian team likely uses it means mostly static APIs. Meaning a stable interface to develop software against.
The way the users mostly understand it means stable software, no major bugs or crashes.
And while those two are linked, they’re not the same. Anecdotally, I’ve used Arch for over 10 years and had only three breakages. Two because I forgot to check for manual intervention before upgrading and one because the battery of the laptop died during an upgrade. All were easily fixed from a live environment, no reinstall necessary. Yes, there were bugs and even crashes in software, but those were upstream issues. I admit that’s not a distinction a user is likely to make. I still consider Arch the most stable distro I’ve ever used.

The latest version of anything is at least 6 months old.