Three Dollar Quill

Aw, come on!

But—

Fine...

from __future__ import annotations

import abc
import typing


class Combinable(typing.Protocol):
    """Protocol for classes whose instances can be combined."""

    @abc.abstractmethod
    def combine(self: T, __other: T) -> T:
        """Combine two instances of the same type."""
        return self.combine(__other)


T = typing.TypeVar("T", bound=Combinable)

It's unaesthetic. Besides, I haven't actually touched any code yet. That up there is the prototype. This whole exchange was a rhetorical framework to give me an excuse to write the code.

Yeah! It's all like "So, you specifically want a union to be considered to implement a protocol? Yeah sure I'll add that to my worldview."

All right, I'll try to follow that advice, and not solely because I just got tired of typing this post in two voices.

Looking for modules without many dependencies. Let's see...

• artifact: definitely not
• box: an odd case; it only relies on some modules that are in this list for sure, but its actual usage is pretty specific to the matrix concept
• combinable: for sure
• entry: doesn't import anything, but I doubt anyone else would want to rely on it, so what would the value be in breaking it out further?
• environment: somehow tangled up in "core" logic, so presumably no
• executable: I mean, it would be possible to make a fully generic version of the data type and then simply specialize it, but that's the kind of code someone writes to win a really unimportant argument
• installer: the key thing here is the reliance on matrix; which sounds like it should be generally useful, but actually isn't
• invocation_environment: builds on a bunch of "core" code, which presumably somehow explains how this file manages to feel "short" at 200+ lines
• label: I would happily publish this in a standalone package, and nobody would use it; you may not like it, but this is what peak performance looks like
• matrix: on close inspection and consideration, this code is actually really close to being some kind of standalone thing; actually pushing it the rest of the way would involve some extra type variables, which this module already has in abundance, and also the API surface is currently not remotely stable
• not_output: not worth thinking about
• parametric_command: confusing and unstable
• path_with: if I can get combinable out, I'd love to have this follow; it relies on various bits of code that don't specifically pertain to MOTR
• program: meh
• runner: heavy usage of "core" functionality
• selection: it can go where box goes; which is, for now, right where it is
• bonus modules: dependent_mapping, saltate and validators, which just make sense to give their own packages

All in all, this only gives us a few packages with license to ignore them:

• combinable
• dependent_mapping
• label
• path_with
• saltate
• validators

The really valuable ones to remove are dependent_mapping and saltate, because they slow down testing.

As far as organizing things, I'd like to pull out the matrix ecosystem into its own submodule at least, but the circular dependency between matrix and artifact, as well as artifact's various "core" dependencies makes me not like that. Perhaps if I could find a non-obnoxious way to break the dependency.

Anyway, one thing that's getting hammered home from inspecting the usages of the various modules is that I really should move cmd.PathStr into some kind of generally usable module, because many modules import cmd only for PathStr.

I think, ultimately, I can only take typing up notes so far. I'm going to have to print out a module listing and scribble on it.

Not right now, though. I think I taxed my eyes a bit writing this, so I'm going to get away from my laptop.

Good night.