...heh. Real-world syntax, huh? Excellent question! Allow me to now regurgitate my younger self ad naseum until we all get sick of dependent typing and, by extension, me.

So I Dub This Shambolic Nightmare...

beartype.vale.IsArgumentative! Of course, that name is awful. That's just how @beartype roll. We accept an awful nomenclature and then exhaustedly run many miles under that heavy load, which we later regret but can no longer rename without breaking PyTorch and the basis for American supremacy itself.

beartype.vale.IsArgumentative generalizes beartype.vale.Is. It's probably best to keep these two validators separate. The central dogma here is that:

• Like Is:
  • IsArgumentative is subscripted by a single callable – typically, a lambda function for convenience. Laziness. Laziness is what I'm saying.
  • The first argument accepted by the callable subscripting IsArgumentative is the current object being type-checked (e.g., l for the list[int] type hint above).
• Unlike Is:
  • The callable subscripting IsArgumentative is required to accept two or more arguments.
  • All arguments following the first argument accepted by the callable subscripting IsArgumentative are the names of parameters accepted by the parent callables annotated by this IsArgumentative validator.

That final bullet point is the beating heart of IsArgumentative. In a pre-cracked nutshell, IsArgumentative facilitates communication between calls to external callables and type hints by forwarding parameters of interest passed to those calls onto those type hints.

...uhh. Can We Get Funny Again? I Had More Fun Back in Those Days.

Those days were just a few paragraphs above! And those days were useless. We didn't do anything except sit around trading diabolical puns and cutthroat jibes with keyboards. Things are better now. Our keyboards are doing something useful for once.

Admittedly, that "something" is confusing even me. Let's put a concrete spin on things by reframing your above examples in terms of this bold and disturbing new IsArgumentative reality:

from beartype import beartype
from beartype.vale import IsArgumentative  # <-- *IMPORTED FOR TRUTH*
from typing import TypeAlias, TypeVar, Annotated 

@beartype
class MyInterface:
    length: Final[int]
    
@beartype
class MyImpl(MyInterface):
    length = 8
        
T = TypeVar('T', bound=MyInterface)

@beartype
class Example(Generic[T]):
    
    # I use an alias here for simplicity, but I would want the same in a function signature.
    MyAlias: TypeAlias = Annotated[list[int], IsArgumentative[
        lambda l, t: len(l) == t.length]]  # <-- *OMG* the truth stuns my eyes like a UAP on fire
    
    @beartype
    def my_function(self, t: T, xs: MyAlias) -> None:
        pass
    
Example().my_function(MyImpl(), [i for i in range(8)])

Above, we see that the MyAlias type hint now "reaches around" and into the open kimono of the Example.my_function() method – directly accessing the exact same t parameter as passed to that method. Likewise:

@beartype
class Example2:
    TheMadness: TypeAlias = Annotated[list[int], IsArgumentative[
        lambda l, self: len(l) == self.member]]  # <-- *WOAH* more promiscuous function invasions

    member: int

    def __init__(self, member: int) -> None:
        self.member = member

    def do_something(self, list: TheMadness) -> bool:
        return True

Again, we see that the appropriately named TheMadness type hint slyly insinuates itself into the namespace of the Example2.do_something() method – directly accessing the exact same self parameter as passed to that method.

IsArgumentative: Pretty Sucky Name, Bro

...yeah, yeah. I know. No one is quite sure what my younger self was thinking. He probably thought he was being funny. Instead, he was just being annoying. You're on notice, younger self. My older self is no longer amused.

Let's charitably assume that we still go with the name IsArgumentative. There's no guarantee we will... but we might. And that's a hope to cling to.

Since @beartype silently ignores validators it doesn't understand or recognize, syntax like the following should be fairly future-proof against horrifying thrilling innovations under some prospective future @beartype API:

class IsArgumentative(object):
    '''
    Placeholder validator factory for the prospective third-party
    :class:`beartype.vale.IsArgumentative[...]` validator factory
    that has yet to exist (but really should).

    This factory implements **dependent typing** (i.e., typing
    that conditionally depends on the values of parameters passed
    to callables annotated by :pep:`593`-compliant
    :obj:`typing.Annotated` type hints of the form
    ``Annotated[{{type_hint}}, IsArgumentative[
        lambda obj, parameter_name: *DO COOL STUFF HERE*]]``).

    Pretend this makes sense.
    '''

    @classmethod
    def __class_getitem__(cls, item: object) -> object:
        return object  # <-- silently reduce to a noop for now *sigh*

# In theory, everything will be legal someday. In practice, nobody knows.
NaturalLessThan = Annotated[int, IsArgumentative[lambda _, n: 0 <= _ < n]]
FixedSizeSet = Annotated[set[T], IsArgumentative[lambda _, k: len(_) == k]]

def _nat_to_nbag(
    x: Natural,
    n: Natural
) -> Collection[NaturalLessThan]:
    ...

def _nat_to_kcomb(
    x: Natural,
    k: Natural
) -> FixedSizeSet:
    ...

You should now be thinking:

"But... that's sucky? Like, you're hard-coding the name of the parameters n and k in those validators. They're not reusable across callables! @beartype-style dependent typing is simply awful."

Hard-code Parameter Names: Even Suckier, Bro

...yeah, yeah. I know. All of this was specced out before PEP 695-style type aliases were even a twinkle in Guido's eye. Now that PEP 695 exists, it'd be super-nice to augment the above with type alias superpowers: e.g.,

type NaturalLessThan[N] = Annotated[int, IsArgumentative[lambda _, N: 0 <= _ < N]]
type FixedSizeSet[K] = Annotated[set[T], IsArgumentative[lambda _, K: len(_) == K]]

def _nat_to_nbag(
    x: Natural,
    n: Natural
) -> Collection[NaturalLessThan['n']]:
    ...

def _nat_to_kcomb(
    x: Natural,
    k: Natural
) -> FixedSizeSet['k']:
    ...

That's a lot hotter, right? I agree. Is that even PEP-compliant or practically feasible, though? No idea. It probably constitutes abuse of PEP 695, which never intended type aliases to be used to dynamically generate third-party PEP 563-compliant typing.Annotated[...] validators subscripted by arbitrary strings like 'n' and 'k'.

Usually, strings in type hints are interpreted as forward references to types that have yet to be defined. Above, we abuse strings in type hints to instead be interpreted as parameter names accepted by the callable annotated by those type hints.

@beartype might be fine with that – but old-school static type-checkers like mypy and pyright probably will not be fine with that. A solution that angers old-school static type-checkers isn't a great solution, because most users (old-school or not) still use those type-checkers. Which means...

We're Back to the Even Suckier API, Doesn't API?

Yup! That's exactly it. You nailed it in one. The suckier API may demonstrably suck, but at least it doesn't anger old-school static type-checkers. Although bad, this is the only API I can conceive of at the moment that satisfies everyone's hidden desires:

NaturalLessThan = Annotated[int, IsArgumentative[lambda _, n: 0 <= _ < n]]
FixedSizeSet = Annotated[set[T], IsArgumentative[lambda _, k: len(_) == k]]

Oh, well. So it goes. Not even my beloved @beartype users can get anything they want. 😭